Connection pooling

Fewer connections is faster

The counterintuitive result that fixes most database-overload incidents: reducing pool size increases throughput and lowers latency.

A Postgres backend is an OS process. Each connection costs memory, a slot in every internal lock table, and a share of CPU spent context switching and thrashing caches. Past the point where all cores are busy, more connections add contention and nothing else.

The mechanism is queueing. With 500 connections, 500 queries interleave, each taking far longer, all finishing late. With 20, queries run to completion quickly and the rest wait in an orderly line. Same throughput, better latency, no thrashing. Queueing in the pool is cheap. Queueing inside the database is not. See queueing-and-utilization.

Sizing

From the HikariCP documentation, derived from Oracle guidance:

connections = (core_count x 2) + effective_spindle_count

For a modern 8-core server on SSD that is roughly 16 to 20, not 200.

Cross-check with Little's Law: 500 queries/sec at 5ms each needs 500 x 0.005 = 2.5 concurrent connections. A pool of 10 gives 4x headroom. Anything beyond buys nothing.