Starlight ToolsDatabase Connection Pool Size Calculator
Estimate pooled database connections per application instance from peak throughput, average checkout-to-return latency, deployment scale, utilization target, and the database connection budget.
How to size a database connection pool
- Use the real peak rate: enter a sustained peak or meaningful high percentile for application requests that reach this database path.
- Count connection usages: count separate checkout-to-return cycles per application request. If one checkout spans the whole transaction, use one usage and its total hold time.
- Measure hold time: use pool metrics or tracing under production-like load. Query-only latency understates occupancy when application code holds the connection longer.
- Model maximum deployment scale: include autoscaling, blue/green overlap, rolling deployments, workers, and failover instances that may coexist.
- Reserve database capacity: subtract operational access and other workloads from the database connection limit.
- Load-test around the result: compare throughput, checkout latency, pending requests, database CPU, I/O, locks, and query latency. Prefer the smallest pool that meets the service objective.
Formula and assumptions
Database usage rate: application requests/s × DB usages/request.
Average busy connections: DB usages/s × average hold time in seconds. This is Little’s Law applied to checked-out connections.
Designed busy concurrency: average busy × (1 + headroom %).
Logical total pool: ceil(designed busy ÷ target utilization).
Pool per instance: ceil(logical total pool ÷ maximum app instances).
Provisioned total: pool per instance × app instances.
Throughput ceiling at target use: pool connections × target utilization ÷ (DB usages/request × hold time seconds).
Application DB budget: DB connection limit − operational reserve − other clients.
The arithmetic assumes independent, evenly distributed requests and a stable average hold time. It does not model queueing distributions, transaction locks, database CPU or I/O saturation, connection establishment, or one request holding multiple connections simultaneously.
Worked example: 1,000 requests per second
Suppose each request uses the database twice, each checkout lasts 12 ms on average, six application instances may coexist, the target pool utilization is 75%, and burst headroom is 25%.
1,000 × 22,000 DB usages/s
2,000 × 0.01224 average; 30 with headroom
ceil(30 ÷ 0.75)40 logical connections
ceil(40 ÷ 6)7 each; 42 provisioned
If the database limit is 200, with 20 reserved and 20 used elsewhere, the application budget is 160. The 42-connection recommendation fits with 118 connections remaining for growth or uncertainty; that remainder is not a reason to consume all 118.
Limits and production checks
- Latency changes under load: a hold-time sample taken below saturation can be too optimistic. Recalculate with production-like or high-percentile observations.
- Large pools can reduce throughput: database CPU, disks, locks, memory, caches, and schedulers impose concurrency limits before the connection maximum is reached.
- Traffic may not balance evenly: instance-local pools need enough margin for skew, sticky traffic, workers, and deployment transitions.
- Multiple checked-out connections need another constraint: if one thread or request can hold several connections simultaneously, validate pool-locking and deadlock risk separately.
- Proxies change the budget: PgBouncer, RDS Proxy, Cloud SQL connectors, and other intermediaries may multiplex client connections onto a different number of database sessions.
- Timeouts still matter: configure finite acquisition timeouts and monitor pending requests, timeout rate, usage duration, active/idle counts, and leak indicators.
Engineering limit: this is a first-pass capacity model, not a guarantee of latency, throughput, or database safety. Confirm the smallest suitable pool with production-like load testing and database-specific limits.
Frequently asked questions
How do I calculate database connection pool size?
Estimate average busy connections as database usages per second multiplied by average connection hold time. Add burst headroom, divide by the target utilization, round up, and distribute that total across the maximum concurrent application instances.
What latency should I enter?
Use observed checkout-to-return time, ideally under production-like peak load. It can include network delay, query execution, locks, and any application work performed while the connection remains checked out.
Why not make the pool as large as the database maximum?
The server limit is a hard connection budget, not an optimal concurrency target. More active work can increase contention and latency. Load-test to find the smallest pool that meets throughput and response-time objectives.
Should every application instance have the same pool size?
Equal sizes are a useful starting point for evenly balanced traffic. Run separate budgets for unlike worker types, or add measured headroom for routing skew and failover.
What if several queries share one transaction checkout?
Enter one database usage and use the total time the connection remains checked out. Do not multiply query count by a duration that already spans the transaction.
Does this predict connection wait latency?
No. Wait-time distributions depend on arrival and service-time variation, pool implementation, timeouts, database saturation, and locks. Use pending-request and acquisition-time metrics under load.
How should autoscaling affect the budget?
Use the maximum instance count that can coexist during scale-out, deployments, and failover. A safe per-instance value can exceed the database budget when multiplied by too many replicas.
Does this page send my inputs anywhere?
No. Calculations, copying, and CSV generation occur in your browser. Inputs are not submitted to a calculation backend.
Method and configuration sources
- HikariCP: About Pool Sizing — why a smaller, tested pool can outperform an oversized pool and why sizing depends on the deployment.
- HikariCP configuration documentation — maximum pool size and connection timeout behavior.
- PostgreSQL: Connections and Authentication — maximum and reserved connection-slot semantics.
- Oracle Universal Connection Pool: Controlling Pool Size — initial, minimum, and maximum pool controls.
Documentation checked 28 July 2026. Vendor defaults are not used as recommendations because database capacity, workload shape, proxies, and pool behavior differ.