Hi, On Thu, May 7, 2020 at 6:08 PM Rory Campbell-Lange <r...@campbell-lange.net> wrote:
> On 07/05/20, Avinash Kumar (avinash.vallar...@gmail.com) wrote: > > >> Our application serves multiple tenants. Each tenant has the schema > > >> with a few hundreds of tables and few functions. > > >> We have 2000 clients so we have to create 2000 schemas in a single > > >> database. > > > > That is one option but I wouldn't say you must. If you cannot get > > > individual tables to be multi-tenant you are probably better off > having one > > > database per client on a shared cluster - at least given the size of > the > > > schema and number of clients. > > > > > I am working on a similar problem. > > 1 database per each client may be a killer when you have a connection > > pooler that creates a pool for a unique combination of (user,database). > > One of our clusters has well over 500 databases fronted by pg_bouncer. > > We get excellent connection "flattening" using pg_bouncer with > per-database connection spikes dealt with through a reserve pool. > What if you see at least 4 connections being established by each client during peak ? And if you serve 4 or 2 connections per each DB, then you are creating 1000 or more reserved connections with 500 DBs in a cluster. > > The nice thing about separate databases is that it is easy to scale > horizontally. > Agreed. But, how about autovacuum ? Workers shift from DB to DB and 500 clusters means you may have to have a lot of manual vacuuming in place as well. > > Rory > -- Regards, Avinash Vallarapu +1-902-221-5976
