Archivenetworking
Connection Pools Are a Load-Balancing Decision
A pool per instance multiplies connections; a pool per cluster needs a proxy. Either way, size by concurrency, not by hope.
- Published
- Reading time
- 1 min read
Opening a database connection costs a TCP handshake, TLS, and authentication. Pools amortize that. But a pool per application instance multiplies: 50 pods × 20 connections = 1,000 connections to a database that may handle 200.
Sizing
Use Little's law as a starting point:
concurrency = throughput × latency
If you need 2,000 queries/s at 5 ms each, that is ~10 concurrent queries — a pool of 10–20 is plenty. Bigger pools mostly add queueing and memory on the database side.
Architecture choices
- Per-instance pool: simple; tune max size to
db_limit / instances, and know that autoscaling changes the math. - External pooler (PgBouncer, ProxySQL): multiplexes many clients onto few server connections; transaction pooling breaks session state.
- HTTP/2 or gRPC: multiplexed streams reduce the need for many TCP connections.
Takeaway: the database's connection limit is a global budget. Divide it explicitly, monitor pool waits, and prefer fewer, well-fed connections.