Does anyone run Postgres without PgBouncer?
This article reignites a decade-old debate: is PgBouncer, a ubiquitous connection pooler, a necessary evil or a sign of a fundamental design flaw in Postgres? The author argues that its near-universal adoption by managed cloud providers suggests it should be a built-in feature. Hacker News users chime in, debating its essentiality across various workloads and revealing both strong support for its use and surprising unfamiliarity.
The Lowdown
The author revisits an old article about managing PostgreSQL connections, observing that despite being ten years old, its core message remains relevant: Postgres isn't great at managing many connections directly, necessitating connection poolers like PgBouncer. A survey of major managed Postgres providers reveals that almost all bundle PgBouncer or a similar pooling solution, leading the author to question if this essential component should be integrated directly into Postgres itself, much like MySQL and Mongo handle connections.
- The 'Aftermarket Windshield' Analogy: The author likens using PgBouncer to buying a car without a windshield, where every user must then add a critical, universally needed component.
- Widespread Adoption: A comprehensive table shows that nearly all reputable managed Postgres providers include PgBouncer or a similar proxy, indicating its critical role in production environments.
- Developer Effort: The current status quo leads to wasted effort, as providers and users must understand and configure PgBouncer, navigate its limitations (e.g., with
LISTEN/NOTIFY), and understand its pooling modes. - Call for Reintegration: The article concludes by advocating for Postgres to absorb connection pooling as a core function, streamlining developer experience and reducing operational overhead.
The piece highlights a long-standing architectural challenge in Postgres, provoking thought on whether a widely adopted workaround should become a native feature.
The Gossip
Pooling Perspectives: Is PgBouncer an Essential or Optional Add-on?
The discussion strongly debates the necessity of PgBouncer. Many commenters, especially those dealing with 'non-trivial' or concurrent workloads, consider it essential due to Postgres's process-per-connection architecture, seeing it as critical for stability. Conversely, others argue it's optional for smaller applications or when client-side pooling (e.g., in Go or Java) is effective. Some even express unfamiliarity with PgBouncer, underscoring its varied adoption based on specific use cases and team knowledge.
Postgres's Peculiarities: Architectural Critiques and Alternative Solutions
A significant thread critiques Postgres's fundamental design, labeling its process-per-connection model as 'retrograde' and the primary reason PgBouncer exists, contrasting it with built-in pooling in databases like MySQL and SQL Server. Commenters delve into the complexities PgBouncer introduces, such as its transaction-level pooling limitations which can break session-scoped features like `LISTEN/NOTIFY`. The conversation also explores alternatives like AWS RDS Proxy, Cloudflare's Hyperdrive, and proprietary solutions such as DataDirect, discussing their unique pooling behaviors, benefits, and associated costs.