ClickHouse: PgBouncer throughput scaled 4x with multi-process fleet
Original: We scaled PgBouncer to 4x throughput
Why This Matters
Demonstrates a practical, kernel-level scaling pattern for single-threaded connection poolers in managed cloud Postgres environments.
ClickHouse Managed Postgres achieved 4x PgBouncer throughput by running a fleet of 16 PgBouncer processes on a 16-vCPU AWS EC2 c7i.4xlarge instance, using SO_REUSEPORT for kernel-level load balancing, compared to a single-process baseline.
PgBouncer is single-threaded by design, meaning one process uses only one CPU core regardless of how many cores a machine has. On a 16-vCPU instance, this leaves 15 cores idle while the pooler becomes the throughput bottleneck before Postgres itself runs out of capacity.
ClickHouse Managed Postgres addresses this by running a fleet of PgBouncer processes scaled to the number of available cores. Each process binds the same port with SO_REUSEPORT enabled, allowing the Linux kernel to load-balance incoming connections across all processes. Clients connect to a single endpoint with no awareness of the underlying fleet.
A key challenge with this approach is query cancellation. Postgres sends cancel requests on new connections carrying a cancel key, and with SO_REUSEPORT, the kernel may route that request to a different process than the one holding the session. ClickHouse solves this through peering: processes are aware of each other and forward misrouted cancel requests to the correct process.
The connection budget is also divided proportionally: max_client_conn and max_db_connections are split across all fleet processes to prevent oversubscription of Postgres. Benchmarks using pgbench in select-only, transaction-pooled mode on identical AWS EC2 instances confirmed the fleet achieved approximately 4x the throughput of a single PgBouncer process.