Connection Pool Sizer
A database connection pool sizer built on Little’s Law. Enter your peak queries per second, average query latency, and how many application instances you run, and get the concurrency you actually need, a per-instance pool size with headroom, and a check against your database’s max-connections limit — so you neither starve requests nor exhaust the database.
A connection pool is sized by one formula you already know: Little’s Law. The number of connections in use at once equals how fast requests arrive times how long each holds a connection. 500 queries per second at 20 ms each means 500 × 0.02 = 10 connections busy on average — so a pool of ~10, plus headroom for bursts, is your floor. Below it, requests queue for a free connection and latency climbs; that queue is the symptom of an undersized pool.
The trap is thinking bigger is safer. Once the pool matches your real concurrency, extra connections buy no throughput — they add lock contention, memory pressure and context-switching on the database, which can make latency worse. This is why guidance like HikariCP’s recommends surprisingly small pools. Size to concurrency plus a margin, not to the largest number the database will tolerate.
The part teams forget is that pools are per instance but the database is shared. Twenty app instances with a pool of 50 each is a thousand connections aimed at a database that might cap out at a few hundred, and every connection costs server memory — past the cap, new connections are simply refused. This tool multiplies your per-instance pool by the instance count and flags when you blow past the limit. When you do, the fix is usually a middle-tier pooler like PgBouncer that multiplexes many client connections onto a few real ones, decoupling your scaling from the database’s hard ceiling.
How it works
- Concurrency = QPS × latency (Little’s Law).
- Per-instance pool with headroom, plus the total across instances.
- Warns when total connections exceed the DB max-connections cap.
- Bigger is not safer — size to real concurrency, not the DB limit.
Frequently asked questions
How do you size a connection pool?
Little’s Law gives the answer: the number of concurrent connections you need equals throughput times latency. If you run 500 queries/second and each holds a connection for 20 ms, you need 500 × 0.02 = 10 connections in flight on average. Add headroom for variance, and that is your pool size. Undersize it and requests queue waiting for a free connection, inflating latency; oversize it and you waste database resources.
Why check against the database max-connections limit?
Because every application instance has its own pool, and they all share one database. If you run 20 instances each with a pool of 50, that is up to 1000 connections hitting a database that may only allow a few hundred — and each connection consumes memory on the server. Exceeding the limit causes new connections to be refused. This tool multiplies your per-instance pool by the instance count and warns if the total exceeds the database’s cap.
Isn’t a bigger pool always safer?
No — this is a common and costly misconception. Past the point where connections match your actual concurrency, extra connections do not add throughput; they add contention on the database (locks, memory, context switching) and can make latency worse, not better. Well-known guidance (for example HikariCP’s) is that small pools often outperform large ones. Size to your real concurrency plus modest headroom, not to the biggest number the database will accept.
What about a connection pooler like PgBouncer?
When many instances would otherwise overwhelm the database, a middle-tier pooler (PgBouncer, pgpool, ProxySQL) multiplexes a large number of client connections onto a small number of real database connections. That decouples your per-instance pools from the database’s hard limit, letting you scale app instances without a linear explosion of database connections. If this tool warns that your total exceeds the cap, a pooler is often the right fix.