Guide
How big should a database connection pool be?
Every application that talks to a relational database keeps a pool of open connections, and one setting decides how many. Too few and requests queue for a connection; too many and the database spends its time switching between them, while each connection costs memory. Most frameworks ship a default of 10, which may be right or badly wrong for your setup. This calculator works out a pool size from your database, your load and the number of app instances.
Why smaller is usually faster
A database can only run as many queries at the same moment as it has CPU cores, plus some overlap while queries wait for disk or the network. Beyond that, extra connections do not add throughput: they wait inside the database, compete for locks and caches, and add context switching. Benchmarks published with the HikariCP pool show throughput rising when an oversized pool is cut down, which is counter-intuitive but consistent.
The starting formula
The PostgreSQL wiki and the HikariCP documentation suggest starting from connections = cores × 2 + effective spindles, where spindles is effectively 1 on SSD storage. For a 4-core database that gives 9 connections for the whole database, a number that surprises people used to pools of 50 or 100. It is a starting point for measurement, not a rule.
Little’s law
Little’s law says the average number of items in a system equals their arrival rate times the time each one stays: L = λ × W. Applied to a pool, the number of connections busy at once equals queries per second times the time each query holds a connection. 400 queries per second at 15 ms each keep 6 connections busy on average. The calculator applies this per app instance and adds 20% headroom for bursts.
Fitting under max_connections
Several app instances each have their own pool, and their sum must stay under the database’s max_connections minus connections reserved for administrators, migrations, cron jobs and monitoring. The calculator divides the available connections by the number of instances to get a cap per instance and never recommends more. When autoscaling can add instances, use the maximum instance count, not today’s.
Threads for mixed work
The threads figure estimates how many worker threads an app server needs when requests spend part of their time waiting on I/O: cores × (1 + wait ÷ compute). With half the time waiting, a 4-core server keeps 8 threads busy. Threads and connections are related but separate; a thread only holds a connection while it runs a query.
A worked example
With the defaults, a 4-core database with max_connections 100 and 10 reserved, three app instances, 400 queries per second at 15 ms and 50% I/O wait, the formula gives 9, Little’s law gives 2 busy connections per instance at peak, and the cap is 30 per instance. The recommendation is a pool of 9 per instance, 27 connections in total, comfortably under the 90 available. The formula line shows the arithmetic: 133.33 requests per second per instance times 0.015 s is 2.00 connections.
When a pooler is the answer
If the instances need more connections in total than the database allows, or the app runs on serverless platforms that create many short-lived instances, put a connection pooler such as PgBouncer in transaction mode between the app and the database. Then many client connections share a small, fixed number of database connections.
Related tools
- Kubernetes Resource Calculator sizes the app pods that open these pools.
- Rate Limit Simulator models the incoming request rate.
- Big-O Calculator estimates how query cost grows with data.
- SQLite Viewer runs queries on an embedded database that needs no pool.
Checked against the current version of the Connection Pool Calculator on .