public inbox for [email protected]  

help / color / mirror / Atom feed

From: Bruce Momjian <[email protected]>
To: Jean Baro <[email protected]>
Cc: [email protected]
Subject: Re: Best practices for preparing an application to (possibly) be sharded (FDW) in the future?
Date: Fri, 11 Feb 2022 15:19:13 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <CA+fQee=OWdDXUcd07Mc_ku1b02EgJzXDr6=pm-gbHY2UjMiBcg@mail.gmail.com>
References: <CA+fQee=OWdDXUcd07Mc_ku1b02EgJzXDr6=pm-gbHY2UjMiBcg@mail.gmail.com>

On Fri, Feb 11, 2022 at 03:56:03PM -0300, Jean Baro wrote:
> 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

Good question.  I think it is generally agreed that sharding would
involve using partitions that point to foreign tables on other servers
using foreign data wrappers.   I have a talk here about it:

	https://momjian.us/main/writings/pgsql/sharding.pdf

So, if you are using partitioning, you are probably ready.  In fact,
with PG 14, you can do read-only sharding in parallel for large data
volumes.

> - Don't make the code (that access PG database) to be much more complicated
> compared to one running on a SINGLE Database (ho sharding)

The clients don't know now they are using partitioning, so my guess is
that they wouldn't know they are using sharding either.

> - No need to change the application's code when (and if) the database needs to
> be sharded in the future (FDW built-in approach).

Right, we never required changes for partitioning either.

-- 
  Bruce Momjian  <[email protected]>        https://momjian.us
  EDB                                      https://enterprisedb.com

  If only the physical world exists, free will is an illusion.

view thread (5+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: Best practices for preparing an application to (possibly) be sharded (FDW) in the future?
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox