Re: pg_attribute, pg_class, pg_depend grow huge in count and size with multiple tenants.

From: Rory Campbell-Lange <rory(at)campbell-lange(dot)net>
To: Avinash Kumar <avinash(dot)vallarapu(at)gmail(dot)com>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, samhitha g <samhithagarudadri(at)gmail(dot)com>, pgsql-performance(at)lists(dot)postgresql(dot)org
Subject: Re: pg_attribute, pg_class, pg_depend grow huge in count and size with multiple tenants.
Date: 2020-05-07 21:08:46
Message-ID: 20200507210846.GA17040@campbell-lange.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On 07/05/20, Avinash Kumar (avinash(dot)vallarapu(at)gmail(dot)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.

The nice thing about separate databases is that it is easy to scale
horizontally.

Rory

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Avinash Kumar 2020-05-07 21:17:32 Re: pg_attribute, pg_class, pg_depend grow huge in count and size with multiple tenants.
Previous Message Avinash Kumar 2020-05-07 20:28:21 Re: pg_attribute, pg_class, pg_depend grow huge in count and size with multiple tenants.