| From: | Jean Baro <jfbaro(at)gmail(dot)com> |
|---|---|
| To: | pgsql-novice(at)lists(dot)postgresql(dot)org |
| Subject: | Best practices for preparing an application to (possibly) be sharded (FDW) in the future? |
| Date: | 2022-02-11 18:56:03 |
| Message-ID: | CA+fQee=OWdDXUcd07Mc_ku1b02EgJzXDr6=pm-gbHY2UjMiBcg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-novice |
Hi there,
Just out of curiosity, is there anything that we (as developers) can do on
our code to (all together):
- Have maximum performance while running on a single PG 14.1 database (HA)
(Google Cloud SQL);
- Be prepared (if needed in the future) to migrate the database to a
sharding solution (FDW) once the microservice exceeds the capability of a
single machine
- Don't make the code (that access PG database) to be much more complicated
compared to one running on a SINGLE Database (ho sharding)
- No need to change the application's code when (and if) the database needs
to be sharded in the future (FDW built-in approach).
Our use case is to use PG today and be prepared to scale beyond a single
Google Cloud SQL machine max capability (maybe self-hosted Postgres when
sharding is necessary)
We are a financial institution/Fintech with over 1MM customers (and growing
50% YoY). The new platform will probably be built on top of PG (as the
standard database).
One PG (Cloud SQL) for every microservice.
Any help or suggestion would be appreciated.
Thanks
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2022-02-11 20:19:13 | Re: Best practices for preparing an application to (possibly) be sharded (FDW) in the future? |
| Previous Message | Laurenz Albe | 2022-02-09 15:08:45 | Re: How does Postgres support backwards compatibility |