Database Connection Pool Sizer

Right-size your Postgres, MySQL, or SQL Server connection pool using production traffic patterns instead of guesswork. Provide the highest sustained request rate and observed query durations to calculate concurrent demand, utilization-adjusted pool requirements, and the buffer you should keep for bursty workloads or failover events.

Include the highest sustained query rate you expect during flash sales or batch windows.
Measure P95 application latency from your APM to keep the pool sized for slow paths.
Defaults to 80% so some connections remain idle for bursts.
Defaults to 20% to absorb traffic spikes or failover events.

Validate results with load testing before pushing to production. Always leave headroom for maintenance operations, migrations, and vacuuming.

Examples

  • 750 requests/sec, 45 ms queries, defaults for utilization and buffer ⇒ Concurrent queries at peak: 33.75 • Connections required at 80% utilization: 42.19 • Recommended pool size with buffer: 51 connections • Estimated idle headroom during peak: 17 connections
  • 420 requests/sec, 90 ms queries, 70% utilization target, 10% buffer ⇒ Concurrent queries at peak: 37.80 • Connections required at 70% utilization: 54.00 • Recommended pool size with buffer: 60 connections • Estimated idle headroom during peak: 22 connections

FAQ

Should I use average or P95 query latency?

Sizing against P95 or P99 latency gives you the best cushion. Using averages underestimates tail latency and can leave the pool saturated when a few slow queries run.

How does autoscaling affect the result?

If application servers scale out under load, multiply the recommended pool size by the maximum instance count or use per-instance RPS and latency figures.

What about connection limits on the database server?

Compare the recommendation with the database max_connections setting. If you are close to the ceiling, consider connection pooling proxies such as PgBouncer or rewrite hot paths.

Can I set different buffers for read and write pools?

Yes. Run the calculator separately for each workload with its own RPS, latency, and buffer assumptions so you tailor pools to the traffic mix.

Additional Information

  • Connection pools should rarely exceed 80–85% utilization to avoid head-of-line blocking when downstream latency spikes.
  • The buffer percentage protects you during deploys, AZ failovers, or GC pauses when application workers retry and temporarily double traffic.
  • If you have read replicas or sharded clusters, run the calculator per node so you do not oversubscribe shared infrastructure.

Related calculators