Connections and Pooling Articles

At 2:15 AM on a Black Friday rollout, our Kubernetes cluster spawned 5,400 direct connections to PostgreSQL. CPU hit 100% with zero query throughput. Here is the high-level architecture of why Postgres chokes on connection volume and how connection pooling…

A routine failover promoted the standby in forty seconds — then p99 latency ran at 300 ms for twenty-five minutes while the new primary re-read its working set from disk. The blks_read measurement, pg_prewarm and autoprewarm setup, and the restart…

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.

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.