PgBouncer's single-threaded architecture caps throughput on multi-core machines — one process saturates a single CPU core while the rest sit idle. ClickHouse Managed Postgres solves this by deploying a fleet of PgBouncer processes sized to the available vCPUs, each binding the same port with SO_REUSEPORT enabled so the kernel distributes incoming connections across all processes.

The fleet uses peering to forward cancel requests that land on the wrong process, ensuring cancellation works across the entire pool. Connection budgets (max_client_conn, max_db_connections) are divided per-process so the aggregate never oversubscribes Postgres. Pooling runs in transaction mode, returning server connections to the pool on commit.

Benchmarks on identical c7i.4xlarge instances (16 vCPUs) compared a single process against a 16-process fleet. The single process peaked at 87k TPS and degraded to 77k at 256 clients, pinned at ~97% CPU on one core while the box stayed under 10% utilized. The fleet scaled to 336k TPS — roughly 4x — using ~8 cores with headroom remaining. At 256 clients, the fleet sustained 52% box CPU versus 7.7% for the single process; CloudWatch confirmed 60% vs 16% utilization.

The crossover appears at real concurrency: below 32 clients the single process slightly outperforms, but beyond that the fleet turns the pooler from bottleneck into plumbing. Every ClickHouse Managed Postgres server ships this configuration by default.