Home / AI & DevOps / Database Connection Pool Sizer

AI & DevOps

Database Connection Pool Sizer

Calculate recommended DB pool size per instance using Little's Law, latency, app instance count, headroom, and max connection limits.

database poolconnection poolLittle's LawPostgreSQLHikariCP

Database connection pool sizer

Estimate pool size from QPS, database latency, app instances, utilisation target, headroom, and max database connections.

Database queries/transactions per second, not total users.
Admin, migrations, monitoring, replicas, background jobs.
Often 0–1 for SSD/NVMe/hot cache workloads.
Recommended pool / instance
14
Total recommendation ÷ app instances
Recommended total pool
67
Little's Law + utilisation + headroom
Active connections
10 / 40
Average / p95 concurrency from QPS × latency
Max safe / instance
16
Available DB connections ÷ app instances
Hardware starting point
17
DB cores × 2 + spindles
Current pool coverage
74.6%
50 total configured connections
DB connection budget used
83.8%
80 available after reserves
Sustainable QPS
628.1
At p95 latency and target utilisation
This is a planning estimate. Use production metrics and load tests to tune final pool size.

What this estimate does and does not do

This calculator estimates a starting database connection pool size from measured workload and latency. It is useful for application pools such as HikariCP, pg pools, SQLAlchemy QueuePool, or similar connection poolers.

It does not replace load testing. Database pool sizing depends on query shape, CPU, locks, I/O, transaction boundaries, connection leaks, network timeouts, read replicas, PgBouncer/RDS Proxy, and whether the workload is CPU-bound, lock-bound, or I/O-bound. Use this as a planning baseline, then validate with production-like load tests and metrics.

Formula used

The main workload estimate uses Little’s Law:

active connections = QPS × database hold time seconds

The pool recommendation adds utilisation and burst headroom:

pool total = ceil(active connections / target utilisation × headroom factor)
pool per instance = ceil(pool total / app instances)

The calculator calculates this using both average database time and p95 database time, then uses the larger recommendation.

Hardware sanity check

Many PostgreSQL/HikariCP sizing discussions also use a hardware-side starting point:

useful active DB backends ≈ database CPU cores × 2 + effective spindle count

This is not a law. It is a warning against the common mistake of giving every app instance a huge pool and overwhelming the database. A small busy pool can outperform a large thrashing pool.

Worked example

For 500 database queries per second, 20 ms average DB hold time, 80 ms p95 hold time, 75% target utilisation, 25% headroom, and 5 app instances:

average active connections = 500 × 0.020 = 10
p95 active connections = 500 × 0.080 = 40
average-based pool = ceil(10 / 0.75 × 1.25) = 17
p95-based pool = ceil(40 / 0.75 × 1.25) = 67
recommended total pool = 67
recommended pool per instance = ceil(67 / 5) = 14

If the database allows 100 connections and 20 are reserved for admin, monitoring, migrations, and background jobs, then 80 remain for application pools. With 5 app instances, the maximum safe app-side pool is about 16 per instance.

How to use the result

  • Start near the recommendation, then load test.
  • Watch pool wait time, connection acquisition timeouts, query latency, DB CPU, lock waits, and connection count.
  • If CPU is high and latency rises, increasing pool size may make things worse.
  • If CPU is low and the app waits for connections, a slightly larger pool may help.
  • If many app instances or serverless functions connect directly, use a pooler/proxy such as PgBouncer or a managed database proxy.
  • Optimise slow queries first; shorter connection hold time reduces required pool size directly.

Assumptions and limitations

  • QPS should mean database operations per second, not HTTP requests unless every request uses one DB operation.
  • Hold time should include the time a connection is checked out, not only SQL execution time if the app holds connections while doing other work.
  • The p95-based estimate is conservative but still not a substitute for burst testing.
  • Connection pooling mode matters: session, transaction, and statement pooling behave differently.
  • Long transactions, connection leaks, and open session in view patterns can invalidate the estimate.

Frequently asked questions

How do you size a database connection pool with Little's Law?

Use L = λ × W, where L is average active connections, λ is database requests per second, and W is the average time each request holds a connection in seconds.

Why does the calculator use p95 database time too?

Average latency can hide spikes. P95 hold time gives a more conservative estimate for bursts and slow queries that keep connections checked out longer.

Should I make the pool as large as possible?

Usually no. Too many active database connections can add context switching, lock contention, memory pressure, and higher tail latency.

What is the cores × 2 + spindles formula?

It is a common starting point for useful active database backends: roughly database CPU cores × 2 plus effective spindle count. It is a hardware-side sanity check, not a per-app-instance pool size.

How does this work with multiple app instances?

The total app pool is split across instances. If the database has 80 connections available for apps and you run 5 instances, the safe per-instance cap is about 16 connections before using a proxy or pooler.