From: | Avinash Kumar <avinash(dot)vallarapu(at)gmail(dot)com> |
---|---|
To: | Rory Campbell-Lange <rory(at)campbell-lange(dot)net> |
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:17:32 |
Message-ID: | CAN0TujfLZ22xm0u99B+jsB31R55fQ5OJ2PKgcmr0TZHUPwoTUw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Hi,
On Thu, May 7, 2020 at 6:08 PM Rory Campbell-Lange <rory(at)campbell-lange(dot)net>
wrote:
> 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.
>
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
From | Date | Subject | |
---|---|---|---|
Next Message | github kran | 2020-05-07 21:18:03 | Re: AutoVacuum and growing transaction XID's |
Previous Message | Rory Campbell-Lange | 2020-05-07 21:08:46 | Re: pg_attribute, pg_class, pg_depend grow huge in count and size with multiple tenants. |