Postgres Still Can't Pool Its Own Connections — And Every Provider Papers Over It

A decade after Brandur Leach first wrote about wrangling database connections, his advice hasn’t aged: Postgres handles large numbers of connections poorly, so production setups still lean on local pools, short checkouts, and an external pooler like PgBouncer. Prompted by a shout-out from database writer Ben Dicken, he surveyed the major managed Postgres providers and found that pooling support is effectively universal — nearly all bundle PgBouncer or an equivalent out of the box, with only enterprise-sales outliers like IBM and Oracle as exceptions.

The deeper point is that this ubiquity exposes wasted effort rather than a solved problem. Because Postgres itself doesn’t pool, every provider reinvents its own scheme for wiring up and locating the bouncer, and every user has to learn PgBouncer’s quirks — its pooling modes, tradeoffs, and limitations like broken LISTEN/NOTIFY. Leach likens it to buying a car with no windshield when every other car on the road has one: technically the buyer’s problem to fix, but fair grounds to resent the dealer.

He argues the fix belongs upstream, in Postgres core, so users could get a single URL and port with no caveats — the way MySQL and MongoDB already work. The blocker is the long-running processes-versus-threads architecture debate, which few contributors carry enough weight to move. Given the developer-years already spent working around the gap, he frames built-in pooling as one of the highest-impact operational improvements Postgres could ship.