Why a Pool Exists
Opening a database connection is expensive, and each one consumes memory and a backend process or thread on the server. A connection pool keeps a fixed set of warm connections that requests borrow and return, capping concurrency and avoiding setup cost on every query.
The Counterintuitive Part
Throughput does not rise with pool size forever. The server has a limited number of CPU cores and disk channels. Once active queries exceed what the hardware can run at once, extra connections just queue inside the database, adding context switching and lock contention. A smaller pool often gives lower latency and higher throughput.
A Starting Estimate
A common rule of thumb sizes the pool near the number of cores plus the number of effective spindles, then adjusts under load. The pool should be smaller than the server's maximum connection limit, with headroom for admin and replication.
Watch the Queue
- Rising pool wait time means requests block waiting for a free connection.
- Many connections but low CPU use means they are contending, not working.
- Tune by load testing, not by guessing the largest number that fits.
Key idea
A connection pool caps concurrency, and beyond the hardware's parallel capacity extra connections add contention, so a smaller well sized pool often wins.