Database Connection Pooling Explained

Connection pooling exists because creating a database connection is expensive — not just "a bit slow," but 10–50ms per connection for TCP handshake, authentication, and session setup. At any meaningful request volume, that cost dominates.

What pooling does

• A pool pre-creates a fixed number of authenticated connections and keeps them ready — when a request needs the database, it borrows one from the pool, uses it, and returns it, so the connection overhead happens once at startup, not on every request
• Without pooling on a service handling 1,000 req/sec, you'd need 1,000 concurrent connections — PostgreSQL forks a backend process per connection, so that's 1,000 processes consuming memory even when most are idle

Sizing the pool — smaller than you think

• The common mistake is setting pool size to match thread count or request volume — but the bottleneck isn't connection slots, it's the database CPU and disk
• HikariCP's guidance: pool size = (CPU cores x 2) + effective spindle count — for a 4-core database server, roughly 9-10 connections outperform 200 because the database can only execute that many queries in parallel
• A pool that's too large means hundreds of connections queuing at the database level, consuming memory without gaining throughput

Key HikariCP settings

• maximumPoolSize: the ceiling — start conservative and raise based on observed pool wait time, not instinct
• connectionTimeout: how long a thread waits for a pool connection before throwing; the default 30 seconds is too long for production — set 5-10 seconds so callers fail fast rather than hanging
• maxLifetime: rotate connections periodically so a database failover or firewall timeout doesn't leave broken connections that only fail at query time

In Spring Boot, HikariCP is the default pool. The most important metric to monitor is pool wait time: if threads are consistently waiting for a connection, either the pool is too small or queries are holding connections too long.