connection pooling

Bilingual

We scaled PgBouncer to 4x throughput
2 months ago
- PgBouncer is single-threaded, using only one CPU core even on multi-core systems, which can bottleneck throughput.
- In ClickHouse Managed Postgres, multiple PgBouncer processes are run, scaled to available cores, using so_reuseport for kernel load balancing.
- Query cancellation is addressed via peering: processes forward cancel requests to the correct session owner, ensuring functionality across the fleet.
- Transaction mode pooling returns server connections after commits, with connection budgets split across processes to avoid oversubscribing Postgres.
- Performance tests show a fleet of 16 processes achieves ~336k TPS (4x higher) and utilizes ~8 cores, while a single process peaks at ~87k TPS and uses only one core.
- A single PgBouncer suffices at low concurrency, but under high load, multi-process fleets prevent the pooler from becoming a bottleneck.
Multigres Supports Listen/Notify Across Pooled Connections
2 months ago
- Multigres solves the scaling problem of Postgres LISTEN/NOTIFY by maintaining a shared listener connection that handles subscriptions on behalf of all clients, avoiding per-client session dependencies.
- The pooler uses a single, reserved backend connection for listening, with refcounting for channels to issue one LISTEN/UNLISTEN per channel regardless of client count, ensuring efficient resource use.
- Notifications are delivered asynchronously through a two-level fan-out: from the pooler to gateways via gRPC streams, then to client connections with bounded queues to prevent blocking and match Postgres's best-effort delivery.
- Multigres ensures transactional behavior for LISTEN/UNLISTEN by buffering actions and applying net changes only at commit time, and closes race conditions with readiness handshakes to guarantee no lost notifications.
- The system handles edge cases like reconnection by replaying active channels, matches Postgres quirks such as channel name truncation and quoting, and plans future improvements like cross-shard NOTIFY and stream consolidation.
Why we built yet another Postgres connection pooler
2 months ago
- PgDog is a Postgres proxy designed to scale databases by handling connection pooling more effectively.
- Unlike other poolers such as PgBouncer, it allows clients to keep using SET commands and LISTEN/NOTIFY without requiring code changes.
- It uses a built-in SQL parser to manage connection state and supports multithreading via Tokio for better performance and handling of traffic bursts.
- The tool has been in production for over a year, is open source, and aims to eliminate trade-offs associated with traditional poolers.

connection pooling

We scaled PgBouncer to 4x throughput

Multigres Supports Listen/Notify Across Pooled Connections

Why we built yet another Postgres connection pooler