Connection pooling in multi tenant app. Shared pool vs pool per tenant


I’m building a multi tenant REST server application with Spring 2.x, Hibernate 5.x, Spring Data REST, Mysql 5.7.
Spring 2.x uses Hikari for connection pooling.

I’m going to use a DB per tenant approach, so every tenant will have his own database.

I created my MultiTenantConnectionProvider in this way:

In my implementation I read tenantId and I get information about the database instance from a central management system.
I create a new pool for each tenant and I cache the pool in order to avoid to recreate it each time.

I read this interesting question, but my question is quite different.
I’m thinking to use AWS (both for server instance, and RDS db instance).

Let’s hypothesize a concrete scenario in which I’ve 100 tenants.
The application is a management/point of sale software. It will be used just from agents. Let’s say each tenants has an average of 3 agents working concurrently in each moment.

With that numbers in mind and according to this article, the first thing I realize is that it seems hard to have a pool for each tenant.

For 100 tenants I would like to think that a db.r4.large (2vcore, 15,25GB RAM and fast disk access ) with Aurora should be enough (about 150€/month).

According to the formula to size a connection pool:

I should have 2core*2 + 1 = 5 connections in the pool.

From what I got, this should be the max connections in the pool to maximise performance on that DB instance.

1st solution

So my first question is pretty simple: how can I create a separate connection pool for each tenant seen that I should only use 5 connection in total?

It seems not possible to me. Even if I assign 2 connections to each tenant, I would have 200 connections to the DBMS!!

According to this question, on a db.r4.large instance I could have at max 1300 connections, so seems the instance should face quite well the load.
But according the article I mentioned before, seems a bad practice use hundreds connections to the db:

If you have 10,000 front-end users, having a connection pool of 10,000 would be shear insanity. 1000 still horrible. Even 100 connections, overkill. You want a small pool of a few dozen connections at most, and you want the rest of the application threads blocked on the pool awaiting connections.

2nd solution

The second solution I have in mind is to share a connection pool for tenants on the same DMBS. This means that all 100 tenants will use the same Hikari pool of 5 connections (honestly it seems quite low to me).

Should this the right way to maximize performance and redure the response time of the application?

Do you have a better idea of how to manage this scenario with Spring, Hibernate, Mysql (hosted on AWS RDS Aurora)?


Most definitely opening connection per tenant is a very bad idea. All you need is a pool of connections shared across all users.

  1. So first step would be to find the load or anticipate what it would be based on some projections.
  2. Decide how much latency is acceptable, what is the burst peak time traffic etc
  3. Finally come to number of connections you will need for this and decide on number of instances required. For instance if your peak time usage is 10k per s and each query takes 10ms then you will need 100 open connections for latency of 1s.
  4. Implement it without any bindings to user. i.e. the same pool shared across all. Unless you have a case to group say premium/basic users to say have set of two pools etc
  5. Finally as you are doing this in AWS if you need more than 1 instance based on point 3 – see if you can autoscale up/down based on load to save costs.

Check these out for some comparison metrics

This one is probably most interesting in terms of spike demand

Some more…

Leave a Reply