Postgres Connection Pooling Is Still Unsolved

A new Postgres connection pooler published a 'why we built yet another one' post, and the thread delivered a useful education on why this space keeps seeing new entrants. PgBouncer in transaction pooling mode breaks server-side cursors, so Django's queryset.iterator() stops working. Connection state leaks between clients. ClickHouse published a separate piece on scaling PgBouncer with so_reuseport and sharding limitations. Every solution exposes a new edge case.

The pattern here is that Postgres's connection model was designed for a different era, and the ecosystem has been papering over it with increasingly complex middleware ever since. pgdog, the new pooler in question, is trying to address the sharding problem that PgBouncer handles badly. That is the right problem to pick, given how many teams are hitting read-scale ceilings.

The frustration in the thread is palpable. These are not obscure bugs. The SET command behaving unexpectedly in transaction pooling mode affects real production apps. The fact that we're still building new poolers in 2025 is a signal that the existing tools have real gaps, not just marketing gaps.