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.
Slow deletes usually come from the work around the row: foreign keys, triggers, indexes, WAL, vacuum debt, and transaction size. The fix starts by finding what each deleted row has to pay for.
Wraparound emergencies are preventable, but once warnings start you need a calm runbook: identify old XIDs, unblock vacuum, freeze priority tables, and protect availability.
Plan regressions are painful because the SQL did not change. The work is proving the plan changed, finding the estimate or stats shift, and restoring the safe path.
psql is more capable than people use it for. A handful of meta-commands and shortcuts make it the most productive shell for database work.
pg_stat_statements is cumulative since cluster start or last reset. If you reset it, you lose the data you would have used to debug the next incident.
A useful Postgres health check is not a wall of green checks. It is a short path from symptom to evidence: sessions, locks, slow SQL, vacuum, replication, and WAL.
auto_explain is for the slow plan you cannot reproduce later. It captures the execution plan when the bad thing actually happens.
pgbench measures Postgres throughput under a synthetic workload. It tells you something useful, but only if you understand what its numbers mean.
Production migration review is mostly lock review. The SQL can be correct and still dangerous if it rewrites a table, validates too much, or blocks writes.
JSONB columns are great. JSONB indexing has a steeper learning curve than the docs admit. Here is what works in production.