Stop Guessing.
Start Diagnosing.

The most direct measure of database health. A query that ran in 5 ms last week and now takes 800 ms is telling you something changed — an index was dropped, a table grew past a plan flip threshold, stats went stale.

Indexes that are never scanned waste write throughput on every INSERT/UPDATE/DELETE. Duplicate indexes compound the problem. Invalid indexes — left behind by a failed CREATE CONCURRENTLY — are invisible to the planner and invisible to the eye.

PostgreSQL's MVCC model never overwrites rows in place — every UPDATE creates a new row version. Autovacuum reclaims dead tuples, but it can fall behind under heavy write load. Once dead tuples exceed ~20% of a table, sequential scans slow down and the table's on-disk size balloons.

PostgreSQL spawns a separate OS process per connection. Beyond max_connections every new connection attempt fails with a hard error. Unlike most resources, connection capacity is binary: at 99% you're fine; at 101% the application is down. Sessions stuck in idle in transaction silently hold locks and eat capacity without doing any work.

A single session holding a heavy lock — an ALTER TABLE, a long transaction, a forgotten cursor — can block every subsequent write to that table. PostgreSQL queues them up silently. In minutes you can go from one stuck session to 50 waiting sessions and a fully unresponsive application.

Streaming replication keeps standbys in sync by shipping WAL. When a standby falls behind, stale reads go unnoticed and your failover RTO grows with every second of lag. Replication slots are even riskier — a paused consumer holds WAL on disk indefinitely, eventually filling the volume.

Every transaction in PostgreSQL consumes a 32-bit transaction ID. The counter wraps at ~2 billion. If a database reaches the safety limit without running VACUUM FREEZE, PostgreSQL performs an emergency shutdown to protect data integrity — all connections are refused until the database is brought up in single-user mode. This is the only self-inflicted PostgreSQL failure mode with no fast recovery path.

PostgreSQL's shared_buffers cache is the fastest path to data. A cache hit costs microseconds; a cache miss hits disk and costs milliseconds. A healthy OLTP database should be above 95–99%. A sustained drop signals that your working set has grown past your buffer pool, or a runaway query is evicting hot pages.

Checkpoints flush dirty pages from shared buffers to disk on a schedule. When writes outpace the schedule, PostgreSQL forces extra checkpoints — causing I/O spikes that appear as latency spikes in applications. Backends writing directly to disk (buffers_backend) bypass the checkpoint process entirely and indicate a severely undersized buffer pool.