PgBouncer operates as a single‑threaded process that binds to one CPU core, limiting throughput on machines with multiple cores. In ClickHouse Managed Postgres a fleet of PgBouncer processes is launched, each sized proportionally to the number of available cores, and all processes bind the same port with the so_reuseport socket option. The operating system then distributes incoming connections across the processes, allowing clients to connect to a single endpoint without knowing the number of backend instances. Peering between the processes enables cancellation requests to be routed to the correct process even when they arrive on a different instance. In transaction mode, a server connection is returned to the pool immediately after a transaction commits, and the total connection limit is divided among the fleet members, preventing oversubscription of Postgres.

Performance testing on identical AWS c7i.4xlarge instances compared a single PgBouncer process with a fleet of sixteen processes under a pgbench load ranging from eight to 256 concurrent clients. The single process reached a peak of approximately 87,000 transactions per second and declined to about 77,000 at 256 clients as the core became saturated. The fleet achieved roughly 336,000 transactions per second, a fourfold increase, while maintaining CPU utilization around 52 percent compared with the single‑process instance’s 9 percent.

Metrics from CloudWatch and in‑guest monitoring showed that the single‑process box averaged about 16 percent CPU utilization, while the fleet averaged about 60 percent during the load. The connection ceiling also differed: the single process enforced its own max_client_conn limit, causing new client connections to be rejected once the limit was exceeded, whereas the fleet allowed a higher aggregate connection count without exceeding each process’s safe limits.

The fleet configuration is the default deployment in ClickHouse Managed Postgres, providing higher throughput and better CPU efficiency without requiring changes to the underlying PostgreSQL instance.