Database Connection Pool Size Calculator
Use measured peak traffic and connection hold time to estimate the pool your application needs, then compare it with the database capacity available to every concurrent instance.
Recommended maximum pool per instance3
- Average busy connections
- 6
- Workload-required total pool
- 10
- HikariCP active-connection ceiling
- 16
- Available database connection budget
- 80
- Provisioned application connections
- 12
- Binding constraint
- Workload demand
- Capacity status
- The recommended pool can satisfy the modeled demand at the selected utilization.
Pool sizes are equal per instance and assume every configured instance can be active at the same time.
The HikariCP formula is a load-testing starting point, not a universal database limit.
How to use this calculator
- Enter a sustained peak request rate and the number of distinct connection checkouts each request makes.
- Measure the average time from checking out a connection to returning it under production-like load.
- Count every application instance that could be running during autoscaling, deployment overlap, or failover.
- Enter the database connection limit, the slots you must protect, and connections already used elsewhere.
- Use the recommendation as a test point, then load test nearby pool sizes with representative traffic.
How to calculate database connection pool size
The calculator starts with the number of connections that are busy at the same time. Little's Law expresses that as L = R × Q × (H ÷ 1000), where R is peak requests per second, Q is connection checkouts per request, and H is average checkout-to-return time in milliseconds. This is a workload estimate, not a count of application threads.
It then adds burst headroom and divides by the target utilization: D = ceil(L × (1 + B) ÷ U). D is the required total pool across all instances, B is headroom as a decimal, and U is the planned busy share of the pool. The calculator divides that total by the maximum number of concurrent instances and rounds up, so each instance has the same workable maximum.
Capacity ceilings matter too
A pool cannot ignore the database server. The HikariCP starting heuristic is C = 2K + S: twice the physical core count K, plus effective spinning disks S. HikariCP describes this as a benchmark-informed starting point, and says to exclude hyperthreads. For an SSD-backed or fully cached workload, use zero effective spindles; faster storage does not automatically justify more active queries.
The other ceiling is the connection budget: A = max(0, M − Z − O). M is the configured database maximum, Z is the operational reserve, and O is occupancy from other clients. PostgreSQL's max_connections is a concurrent-server-connection limit, and increasing it also allocates more server resources. Keep recovery, monitoring, migrations, and direct-access slots out of application pools.
The tool uses the smaller of C and A, divides it equally among instances, and takes the smaller of that per-instance limit and the workload requirement. It reports which of workload demand, the hardware heuristic, or the database budget binds. If the limit cannot allocate even one connection to every instance, there is no feasible equal-sized pool under the inputs.
What moves the result most
Hold time is often the most useful number to improve: holding a connection for 40 ms instead of 20 ms doubles the average busy count at the same request rate. Deployment count also matters because all instances compete for one database. Do not size the pool from web-server threads alone; threads can wait safely for a connection, while an oversized active-query count can increase contention and context switching.
What this estimate leaves out
The calculation does not model query mix, lock waits, transaction contention, CPU cost, cache misses, network stalls, or long-tail connection hold times. A proxy such as PgBouncer can introduce separate client-pool and database-session limits. Load test the recommendation and nearby lower and higher values with production-like peak traffic before treating it as a production setting.
Worked example
Suppose an application sustains 300 requests per second, makes one checkout per request, and holds each connection for 20 ms. The average busy count is 300 × 1 × (20 ÷ 1000) = 6. With 25% headroom and a 75% utilization target, the required total pool is ceil(6 × 1.25 ÷ 0.75) = 10.
Across four concurrent instances, each instance needs ceil(10 ÷ 4) = 3 connections. An eight-core database with no effective spindles has a HikariCP ceiling of 2 × 8 + 0 = 16, while a 100-connection database after 10 reserved and 10 other-client connections has an 80-connection budget. The hardware ceiling allows four per instance, so the recommendation is three per instance and 12 provisioned application connections. The extra two reflect equal per-instance rounding.
Common questions
Should I size a connection pool from requests per second or thread count?
Use request rate together with measured connection hold time. Little's Law estimates concurrent busy checkouts from those two quantities and is more direct than application-thread count. Threads that are not actively using a database connection should not require a connection in the pool.
What connection hold time should I measure?
Measure from the pool checkout until the application returns the connection, under traffic and query patterns close to a meaningful peak. Include transaction work, result processing, and remote calls only if the application actually holds the connection during them. Review percentiles too, because an average can hide a damaging long tail.
Why can a smaller connection pool improve throughput?
The database can only make useful progress on a limited number of active queries. Beyond that point, more connections can add CPU scheduling overhead, lock contention, cache pressure, and I/O competition. A smaller pool lets excess application work wait at the pool instead of making the database do more concurrent work than it can handle.
How do autoscaling and rolling deployments affect pool size?
Every concurrently running instance can open its configured maximum, including old and new versions during a rollout. Size against the highest realistic simultaneous instance count, not the steady-state count. If that count rises, the equal per-instance share of the database budget falls unless the database capacity also changes.
Does PgBouncer or another connection proxy change the calculation?
Yes. A proxy can pool many client connections onto fewer database sessions, so its client-side pool and its database-side limits need separate review. This calculator still helps estimate application checkout demand, but the configured database-session count must reflect the proxy mode and its own contention behavior.