Notes for the problems that show up after launch: bad plans, awkward migrations, index debt, vacuum pressure, replica lag, and the small decisions that make PostgreSQL easier to operate.
Azure Database for PostgreSQL has strong platform metrics, Query Store, enhanced metrics, and portal dashboards. This guide explains how to turn those signals into PostgreSQL incident evidence.
AWS RDS PostgreSQL removes server ownership, but it does not remove query risk. This field guide shows what to watch across CloudWatch, Database Insights, Enhanced Monitoring, and PostgreSQL itself.
Google Cloud SQL for PostgreSQL gives you Cloud Monitoring, logs, and Query Insights. This field guide shows how to connect those GCP signals to query, lock, vacuum, and replica evidence.
An OS upgrade changed glibc's collation, your text indexes were now sorted by rules that no longer match, and PostgreSQL had no idea. Queries return wrong results and unique constraints let duplicates in.
Triggers are convenient and almost invisible, which is exactly why a bulk update can grind to a halt. Each row fires logic you forgot was there, and the cost compounds quietly until a batch job exposes it.
Subtransactions are cheap until you cross 64 of them in one transaction or pile up enough of them under load. Then SubtransSLRU contention shows up as global slowness nobody can explain.
TOAST quietly moves your large values off-page and compresses them. It's invisible until a query that only touches small columns suddenly drags, and the cause is a wide column you forgot was there.
Foreign tables look local, which is the problem. A join the planner can't push down pulls an entire remote table across the network row by row, and a clean-looking query becomes a multi-minute transfer.
The planner assumes your columns are independent. When they're actually correlated, its row estimates collapse, it picks a nested loop over a hash join, and a fast query becomes a slow one. CREATE STATISTICS fixes the math.
Loading millions of rows with single-row INSERTs is the slowest possible choice. COPY, batching, building indexes after the load, and managing WAL turn an overnight job into a coffee break.
Swapping two rows' unique values failed halfway through with a duplicate-key error, even though the end state was perfectly valid. Deferrable constraints let PostgreSQL check at commit instead of after every row.
Everyone learns about transaction ID wraparound eventually. Then one day the log says 'MultiXactId members limit exceeded' and you discover PostgreSQL has a second counter that can run out — and it's usually your foreign keys filling it.