Database connection pool calculator
Too few connections and requests queue; too many and your database falls over. Find the pool size your app actually needs at peak — and whether you're about to exhaust your database's connection limit.
Your setup at peak
Postgres defaults to 100 max connections; managed databases reserve some for the system. Check your own max_connections.
peak RPS × queries/request × query time (s) — Little's Law for in-flight database work. If that exceeds the connections your app can open (instances × pool size), requests queue waiting for a free connection. The recommended pool adds ~30% headroom and divides across instances.
A planning estimate. Real needs depend on your query mix, transactions, long-running queries and connection poolers — load-test to confirm.
How many database connections do you actually need?
A database connection pool is a fixed set of open connections your app reuses instead of opening a new one per request. Size it from the work in flight at peak, not from a round number someone copied off Stack Overflow. The math is Little's Law: the average number of connections busy at any moment equals your peak query rate multiplied by how long each query holds a connection. Pick a pool that covers that with headroom — and no larger, because every connection consumes memory and scheduler time on the database.
The trap is connection starvation at one end and exhausting Postgres max connections at the other. Each app instance opens its own pool, so the total your fleet can demand is instances × pool size. When that exceeds the database's limit, connections get refused and the database itself becomes the bottleneck. The usual fix at scale is not a bigger app-side pool but a connection pooler like PgBouncer in transaction mode that multiplexes thousands of clients onto a handful of real backends.
| Symptom | Likely cause | Fix |
|---|---|---|
| Requests hang / time out at peak, CPU fine | In-flight queries > available connections | Raise pool, shorten queries, add read replicas |
| "too many clients already" errors | instances × pool > db max connections | Add PgBouncer or lower pool size |
| More connections, no more throughput | Contention past the database's sweet spot | Pooler in front; right-size the pool down |
Your database shouldn't be the ceiling.
If requests queue at peak or you keep hitting connection limits, the fix is rarely guesswork. We profile real query load, size pools, add a pooler where it belongs, and design the read path to scale. Book a free build audit and we'll find where your throughput actually stops.
Book a Build AuditConnection pool questions
How do I size a database connection pool?
Estimate the number of queries in flight at peak: peak requests per second times queries per request times average query time in seconds. That's the minimum connections you need across all app instances. Divide by your instance count, add ~30% headroom, and that's a sane pool size per instance — capped so the total never exceeds your database's max connections.
Why does a bigger connection pool sometimes make things worse?
Databases have a hard connection limit and each connection costs memory and scheduling overhead. If every app instance opens a large pool, the total can exceed the database's max connections and starve or crash it. Past a point more connections add contention, not throughput — a connection pooler like PgBouncer in front of the database is usually the fix, not a bigger app-side pool.
What are signs of connection starvation?
Requests that intermittently hang or time out under load while CPU looks fine, errors like 'too many clients' or 'pool timeout', and latency that spikes at peak then recovers. It means in-flight queries exceed available connections, so requests queue waiting for a free one.