IdeaWell

Project ideas from Hacker News discussions.

Does anyone run Postgres without PgBouncer?

Original Article

Hacker News Discussion

📝 Discussion Summary (Click to expand)

Three dominant themes from the discussion

Theme Summary Supporting quotation
1️⃣ External pooling is often essential for production workloads Most respondents agree that managing hundreds of simultaneous PostgreSQL connections without a pool quickly exhausts the server, so a dedicated pooler (e.g., PgBouncer) is a pragmatic necessity for any non‑trivial service. “Every single connection to Postgres is a new process, which requires a fork and new memory allocation (at least 10 MB plus whatever you need for your query).” – aobdev
2️⃣ PgBouncer’s transaction‑pooling model has real limitations Several users point out that PgBouncer’s “transaction pooling” breaks assumptions about a stable backend session, preventing use of features like prepared‑statement caches, transaction‑scoped settings, and seamless failover. Alternatives such as DataDirect are cited for their richer control. “This breaks the assumption that one client connection is the PostgreSQL backend session.” – root‑parent
3️⃣ Many prefer in‑application or built‑in pooling over external proxies A recurring viewpoint is to let the application (or its framework) handle connection pooling, especially in serverless, small‑scale, or language‑specific contexts where the overhead of an extra proxy isn’t justified. “Python: absolutely necessary due to the amount of processes …Java: never felt the need even on quite big apps… As it’s much easier to share a connection pool locally, it’s not as many single connections across the whole app.” – matsemann

The summary is intentionally concise, focusing on these three recurring ideas and the quoted insights that illustrate them.

🚀 Project Ideas

Generating project ideas…

Multi‑Tenant Connection Orchestrator (MTCO)

Summary

  • Provides per‑tenant dynamic connection routing and failover while preserving full PostgreSQL session semantics, eliminating PgBouncer’s transaction‑pooling limitation.
  • Enables SaaS operators to safely scale connections without breaking session‑scoped features.

Details

Key Value
Target Audience SaaS developers with multi‑tenant PostgreSQL back‑ends
Core Feature Dynamic per‑tenant pool sizing + automatic primary/standby failover + optional connection‑state reset
Tech Stack Go, libpq, Redis (state store)
Difficulty Medium
Monetization Revenue-ready: Subscription per active tenant ($0.01 per connection‑hour)

Notes

  • HN users lamented that “transaction pooling breaks the assumption that one client connection is the PostgreSQL backend session,” which MTCO solves without sacrificing session guarantees.
  • The project directly addresses the need expressed for “alternatives that can maintain alternate PostgreSQL servers, retry connections, randomize attempts, and provide explicit failover modes” while avoiding the complexity of DataDirect licensing.
  • Offers a clear upgrade path for teams currently using PgBouncer but wanting multi‑tenant isolation.

Serverless‑Ready PostgreSQL Pool (SR‑Pool)

Summary

  • A lightweight connection pool library that automatically maintains warm connections across serverless function invocations, handling connection limits and timeouts without external proxies.
  • Provides a drop‑in replacement for pg‑pool that works seamlessly in Lambda, Cloudflare Workers, and similar environments.

Details

Key Value
Target Audience Cloud engineers using serverless back‑ends (AWS Lambda, Azure Functions, etc.)
Core Feature Auto‑warm connection pool that persists across cold starts, configurable max‑connections per function, graceful timeout & health‑check handling
Tech Stack Node.js (TypeScript), pg native driver, Docker for local testing
Difficulty Low
Monetization Hobby

Notes

  • Commenters noted “for serverless backend, you normally don’t need it” but also pointed out the lack of a ready‑made solution; SR‑Pool fills that gap.
  • The tool would let developers avoid “adding unnecessary complexity” while still gaining connection reuse, addressing the frustration of “I didn’t know it was still around” and the desire for a simple pooling layer in serverless stacks.
  • Potential for community adoption as an open‑source library with optional paid support contracts.

PgBouncer Migration Analyzer (PgMA)

Summary

  • Static code analysis tool that scans application connection patterns to detect PgBouncer‑incompatible usage (e.g., reliance on server‑side prepared statements, long‑running transactions) and suggests migration strategies.
  • Generates actionable reports and configuration templates for moving to native pooling or alternative routers.

Details

Key Value
Target Audience DevOps engineers and architects maintaining PgBouncer in production
Core Feature Detects transaction‑pooling incompatibilities, maps connection usage heatmaps, recommends pooler changes or code refactors
Tech Stack Python, ast parsing, SQLite for graph analysis, CLI output
Difficulty Low
Monetization Hobby

Notes

  • The discussion highlighted that “PgBouncer’s big technical compromise that is transaction pooling” causes many “session scoped PostgreSQL features [to] not work normally,” a pain point PgMA directly mitigates.
  • Commenters asked “why isn’t connection pooling part of PostgreSQL out of the box?” – PgMA offers a practical way to evaluate that question for existing codebases.
  • By providing concrete migration guidance, the tool would satisfy HN’s appetite for “practical utility” and spark further dialogue on improving PostgreSQL’s native pooling capabilities.

Read Later