PgBouncer's transaction pooling mode is the right call for most fleets, but it silently breaks prepared statements, SET, advisory locks, and LISTEN/NOTIFY. Here is how to run it without the 3am surprises.
PostgreSQL Topic Archive
Connections and Pooling PostgreSQL Articles
Connection storms, pool saturation, PgBouncer behavior, and max_connections pressure.
InnoDB puts almost everything in one big buffer pool, while PostgreSQL splits caching between shared_buffers and the OS page cache. Here is how the two models differ and how to monitor each honestly.
Switching PgBouncer to transaction pooling tripled our connection efficiency and broke prepared statements, SET commands, and advisory locks all at once. The fix starts with understanding what a pooled connection no longer guarantees.
Not every PostgreSQL performance incident is a bad query. Too many connections, idle transactions, pool starvation, and client backpressure can make normal SQL look slow.
Connection storms look like database outages but usually start in pools, retries, autoscaling, deploys, and health checks. The fix is shaping pressure before it reaches Postgres.
Pooling is about protecting Postgres from connection shape, not just increasing throughput. The hard parts are transaction mode, prepared statements, bursts, and failure behavior.
SSL on Postgres is a one-line config change to enable and a multi-day project to do correctly. The default settings are not good enough.
Most Postgres connection strings live in places they should not. Environment variables, config files, scripts, screenshots in Slack. Here is the discipline.