MIME-Version: 1.0
From: Jean Baro <jfbaro@gmail.com>
Date: Fri, 11 Feb 2022 15:56:03 -0300
Message-ID: 
 <CA+fQee=OWdDXUcd07Mc_ku1b02EgJzXDr6=pm-gbHY2UjMiBcg@mail.gmail.com>
Subject: Best practices for preparing an application to (possibly) be sharded
 (FDW) in the future?
To: pgsql-novice@lists.postgresql.org
Content-Type: multipart/alternative; boundary="000000000000484fef05d7c29f3b"
Archived-At: 
 <https://www.postgresql.org/message-id/CA%2BfQee%3DOWdDXUcd07Mc_ku1b02EgJzXDr6%3Dpm-gbHY2UjMiBcg%40mail.gmail.com>
Precedence: bulk

--000000000000484fef05d7c29f3b
Content-Type: text/plain; charset="UTF-8"

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

--000000000000484fef05d7c29f3b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi there,<br><div><br></div><div>Just out of=C2=A0curiosit=
y, is there anything that we (as developers) can do on our code to (all tog=
ether):</div><div><br></div><div>- Have maximum performance while running o=
n a single PG 14.1 database (HA) (Google Cloud SQL);<br>- Be prepared (if n=
eeded in the future) to migrate the database to a sharding solution (FDW) o=
nce the microservice exceeds the capability of a single machine<br>- Don=
9;t make the code (that access PG database) to be much more complicated com=
pared to one running on a SINGLE Database (ho sharding)</div><div>- No need=
 to change the application&#39;s code when (and if) the database needs to b=
e sharded in the future (FDW built-in approach).</div><div><br></div><div>O=
ur use case is to use PG today and be prepared to scale beyond a single Goo=
gle Cloud SQL machine max capability (maybe self-hosted Postgres when shard=
ing is necessary)<br>We are a financial institution/Fintech with over 1MM c=
ustomers (and growing 50% YoY). The new platform will probably be built on =
top of PG (as the standard database).<br>One PG (Cloud SQL) for every micro=
service.<br><br>Any help or suggestion would be appreciated.</div><div><br>=
</div><div>Thanks</div></div>

--000000000000484fef05d7c29f3b--