Running a PgBouncer fleet to 4x connection-pooling throughput

PgBouncer is single-threaded, so one process saturates a single CPU core no matter how large the machine is. On a 16-vCPU box, that one core becomes the throughput ceiling long before Postgres itself is stressed, and the other fifteen cores sit idle. ClickHouse Managed Postgres works around this by running a fleet of PgBouncer processes sized to the core count, all binding the same port with SO_REUSEPORT. The kernel load-balances incoming connections across them, so clients still see a single endpoint while every core does real work.

The fleet approach introduces one problem: Postgres query cancellation arrives on a fresh connection carrying a cancel key, and SO_REUSEPORT may route it to a process that knows nothing about the running session, silently dropping the cancel. ClickHouse solves this with PgBouncer peering, where processes forward misrouted cancels to whichever peer actually owns the session. Pooling runs in transaction mode, and the connection budget (max_client_conn and max_db_connections) is divided across processes so the fleet never oversubscribes Postgres.

Benchmarks on identical AWS c7i.4xlarge instances make the difference stark. A single process peaked near 87k transactions/sec and degraded to 77k under 256 clients while pinned at ~97% of one core and leaving the box under 10% utilized. A 16-process fleet climbed to roughly 336k tps — about 4x — spreading across eight busy cores with headroom to spare. The single process is actually marginally faster at low concurrency, but the gap opens exactly where it matters: under real load, when the pooler rather than the database becomes the wall. The practical lesson is that a lone PgBouncer is a fine default until it caps throughput, at which point fleet + SO_REUSEPORT + peering turns pooling back into invisible plumbing.