Connection pools: 45ms to open a connection vs. 0.2ms to borrow one
TL;DR
Every new database connection goes through TCP, TLS and authentication handshakes — about 45ms in the video. A connection pool keeps connections open so they can be borrowed in ~0.2ms. When traffic exceeds the pool size, requests wait their turn.
Three scenarios
| Scenario | Time to get a connection | Notes |
|---|---|---|
| No pool | ~45ms per request | TCP → TLS → AUTH every time |
| Pool, light load | ~0.2ms | Reuses an open connection, no handshake |
| Burst of 14, pool of 4 | 10ms, 20ms, 30ms… | 10 requests queue for a free connection |
After the burst, idle connections are closed by the idle timeout.
How to put it to work
- Always pool for apps with steady traffic (HikariCP for Java, pgBouncer for PostgreSQL, built-in pools in most ORMs).
- Bigger isn’t always faster: databases cap connections, and too many cause contention that slows everything down.
- Track connection-acquire time as its own metric — rising values mean the pool is too small or queries hold connections too long.
- Serverless: per-instance pools can exhaust database connections — use a proxy such as RDS Proxy or pgBouncer.