>
> How many concurrent connections can be made, will purely depend on number
> of CPUs (cores) you have available on the database server.
> Well, certainly 1 would be the way to go to build an multi-tenant
> application, but, it strongly depends on your application specific
> requirements and how
On 8/1/2016 11:17 PM, Silk Parrot wrote:
Yup, I also would like to go with 1, suppose a server with 16 core,
32GB memory, SSD box, how many connections could it handle roughly,
e.g. O(100) or O(1000) or O(5000)?
thats a fairly small server by today's standards, especially the 32GB
ram part.
Thanks for the response
We are trying build a multi tenant application and are debating which
approach we should take: (also my understanding is based on that pgbouncer
connection pool doesn’t work across different user/database pair):
1. For each tenant, we create a dedicated database and a
On Sun, Jul 31, 2016 at 12:07 PM, Silk Parrot wrote:
> Hi,
>
> We are trying build a multi tenant application and are debating which
> approach we should take: (also my understanding is based on that pgbouncer
> connection pool doesn’t work across different user/database pair):
>
> 1. For each
Hi,
We are trying build a multi tenant application and are debating which
approach we should take: (also my understanding is based on that pgbouncer
connection pool doesn’t work across different user/database pair):
1. For each tenant, we create a dedicated database and a dedicated user. Thi
