HikariCP pool size calculator
Work out a sensible maximum-pool-size from your database limits, number of instances and expected load, and copy the Spring Boot properties.
How big should the connection pool be?
The default HikariCP pool in Spring Boot is 10 connections. For many services that is fine, and for others it is either wasteful or a bottleneck. The usual mistake is to raise the number when requests are slow, which moves the queue from the pool to the database and makes everything slower. The right size depends on three things: how many connections the database can serve well, how many application instances share it, and how many connections your traffic actually needs.
This tool takes the database's max_connections, the connections you want to keep free for admins and migrations, the number of instances, the database CPU and disk, and your expected load and connection hold time. It calculates the budget per instance, the figure that Little's law says your load needs, and a recommendation that stays inside the database limit. It then prints the HikariCP properties for Spring Boot.
Reading the result
- Budget per instance is what each instance may open if all of them are busy at once. Going over it risks "too many connections" errors during a deploy, when old and new pods overlap.
- Load estimate is average concurrency from throughput and hold time. The recommendation adds 50% headroom.
- If the load estimate exceeds the budget, the tool says the database is the limit and suggests a pooler such as PgBouncer, shorter transactions or fewer instances.
Hold time is the number that most often hides a problem. Long transactions, remote calls inside a transaction and open-session-in-view all keep connections busy while the application does something else. Cutting hold time raises throughput without adding a single connection. The numbers are a model: confirm with Hikari's metrics (active, idle, pending) under real load. Nothing you enter leaves your browser.
Frequently asked questions
Is a bigger connection pool faster?
Usually not. A database can only run as many queries truly in parallel as it has CPU cores and disks. Extra connections just add context switching and lock contention. HikariCP's own guidance is that a small pool, sized to the database, often outperforms a large one.
What is the (cores x 2) + spindles formula?
A rule of thumb from the PostgreSQL community for the total number of active connections a database server can use well. It is a starting point to measure from, not a law, and it applies to the whole database, so divide it across your application instances.
What is Little's law here?
Connections needed = requests per second x seconds each request holds a connection. At 150 requests per second with 20 ms held, that is 3 connections busy on average. Add headroom for bursts.
Why set max-lifetime below the database timeout?
If the database, a proxy or a firewall closes idle connections after some time, a pooled connection can die silently. HikariCP retires connections at max-lifetime, so it should be several seconds shorter than any such limit.