July 11, 2026
16 cores, 1 diva, infinite drama
We scaled PgBouncer to 4x throughput
One tiny bottleneck was hogging the whole server — and commenters had thoughts
TLDR: ClickHouse says it made a database traffic manager about four times faster by spreading work across many workers instead of one overworked process. Commenters loved the speedup but instantly turned it into a debate over missing setup details, cloud outage trauma, and whether a different tool would’ve made the whole thing unnecessary.
A database helper that was quietly using just one brain on a 16-brain machine got a glow-up, and the internet immediately turned it into a group project. The basic drama: the team behind ClickHouse Managed Postgres says they took PgBouncer — a tool that manages database connections — from one lonely worker to a whole fleet of them, all hiding behind the same front door. Result: about 4x more throughput, jumping from roughly 87,000 actions per second to around 336,000 under heavy load. In plain English, they stopped paying for a big box that mostly sat around doing nothing.
But the comments? That’s where the real popcorn moment starts. One crowd wanted the receipts immediately, with odie5533 basically yelling, “show the config!” and pasting the kind of setup snippet only true believers frame on the wall. Another camp shrugged and said this isn’t even that exotic: nosefrog noted Kubernetes made running multiple copies pretty easy, then casually dropped the very relatable cloud horror story that Azure VM maintenance can trigger rolling outages across a fleet. Suddenly the article became part performance win, part support group.
Then came the hot-take drive-bys. One commenter asked whether using HAProxy plus multiple PgBouncer instances would’ve been simpler, while another delivered the classic internet power move: “Just use Odyssey” — meaning, why patch around limits when another tool already promises scale? And for pure nerd-comedy, jauntywundrkind stole the show by comparing it to a BitTorrent experiment involving random connections, a “whole rendezvous system,” and passing sockets around like a spy thriller. The vibe was clear: yes, the benchmark is impressive, but the community really wanted to argue whether this was clever engineering, obvious plumbing, or a very fancy way to reinvent something that already exists.
Key Points
- •PgBouncer uses only one CPU core per process, which can bottleneck throughput on multi-core machines before Postgres is saturated.
- •ClickHouse scaled PgBouncer by running multiple processes on the same port with so_reuseport, allowing the kernel to spread connections across cores.
- •Because Postgres cancel requests arrive on separate connections, ClickHouse added peering so a cancel request can be forwarded to the process that owns the session.
- •The deployment uses transaction pooling and divides max_client_conn and max_db_connections across the PgBouncer fleet to avoid oversubscribing Postgres.
- •In AWS EC2 tests on 16-vCPU hosts, a 16-process PgBouncer fleet reached about 336,469 transactions per second versus about 76,893 at 256 clients for a single-process setup.