ClickHouse Scales PgBouncer 4x With Multi-Process Fleet
11 Jul 2026
PgBouncer, the widely used connection pooler for Postgres, has long run as a single process — a design that caps throughput regardless of how many CPU cores a server has. ClickHouse says it has found a way around that limit: running a fleet of PgBouncer processes in parallel using SO_REUSEPORT, a Linux socket option that lets multiple processes bind to the same port.
The result, according to ClickHouse, is a 4x jump in transaction throughput — and the architecture now ships by default in ClickHouse Managed Postgres, which is available in ClickHouse Cloud.
The numbers
- A single PgBouncer process peaks at roughly 87,000 transactions/sec, saturating one core at about 97% CPU utilization.
- A fleet of 16 PgBouncer processes reaches approximately 336,000 transactions/sec — a 4x improvement.
- The fleet spreads work across about 8 cores on a 16-vCPU instance.
- Overall instance CPU utilization rises from 16% (single process) to 60% (fleet), as measured by EC2 CloudWatch.
The core insight is straightforward: PgBouncer's single-process design means one core does all the work no matter how many are available. By running multiple processes that share a listening socket via SO_REUSEPORT, the kernel distributes incoming connections across processes, letting the pooler use far more of the machine's available CPU.
Tradeoffs to weigh
The throughput gains come with a proportional rise in resource consumption — CPU utilization nearly quadruples (16% to 60%), which could mean higher infrastructure costs for teams running this setup themselves. Managing a fleet of 16 processes instead of one also adds operational surface area for teams self-hosting PgBouncer rather than using it through a managed service. The report also notes that these results were measured on a specific 16-vCPU instance and workload pattern, and may not generalize to other configurations.
Several open questions remain unaddressed in ClickHouse's disclosure: the exact benchmark methodology and tools used, whether the 4x gain holds across different instance sizes, the latency impact of the multi-process approach versus a single process, and how this compares to alternative poolers like pgcat. It's also unclear whether the benchmark reflects synthetic load testing or real production traffic.
Why founders should care
For early-stage teams running Postgres at scale, connection pooling is often an invisible bottleneck until traffic spikes expose it. This report suggests that throughput ceilings some teams assume are fixed may actually be addressable through process-level parallelism rather than costlier vertical scaling — though the size of that benefit likely depends heavily on workload and instance type, which ClickHouse hasn't fully detailed.
Teams using ClickHouse Managed Postgres specifically may benefit from this optimization automatically, since the fleet setup is reportedly the default configuration — potentially reducing the manual tuning work some teams currently put into PgBouncer. For everyone else, the higher CPU utilization numbers are a signal worth watching: a 4x throughput gain that also nearly quadruples CPU usage is not free, and founders evaluating similar multi-process approaches should probably model cost against expected connection load before committing.
More broadly, this fits a pattern of managed database providers building performance optimizations directly into their platforms — which could mean less infrastructure tuning work for founders who adopt managed offerings, at the cost of less visibility into what's happening under the hood.