Connection Pooling: PgBouncer
Run PgBouncer in transaction-pooling mode, size pools correctly, and avoid the prepared-statement trap.
Why Pool Connections?
Every Postgres connection is a separate OS process — memory and CPU heavy. Apps that open and close connections per request quickly exhaust the server. Pooling reuses a small set of long-lived connections.
Per-Connection Cost
A typical Postgres backend uses 5–10 MB of RAM. 500 connections = ~5 GB RAM just for backends. PgBouncer can multiplex 1000s of clients onto 50 backend connections.
All lessons in this course
- pg_stat_statements: Top Queries
- pgBadger for Log Analysis
- Connection Pooling: PgBouncer
- Capacity Planning and Bloat Audits