Notes for the problems that show up after launch: bad plans, awkward migrations, index debt, vacuum pressure, replica lag, and the small decisions that keep PostgreSQL, MySQL, MariaDB, and SQL Server easier to operate.
Find the queries dragging your Postgres down, read their plans, and fix them in order of impact.
Read the guide →Which indexes to add, which to drop, and how to spot redundant index debt before it costs you writes.
Read the guide →How autovacuum works, when it falls behind, and how to keep bloat from eating your storage and your buffer cache.
Read the guide →Sizing pools, PgBouncer modes, and how to stop idle-in-transaction sessions from exhausting max_connections.
Read the guide →Track lag, WAL throughput, and replication slots before they turn into stale reads or a full disk.
Read the guide →
Backups, restores, PITR, archive gaps, and recovery drills for PostgreSQL.
AWS RDS, Azure Database for PostgreSQL, Google Cloud SQL, AlloyDB, and managed PostgreSQL monitoring notes.
Connection storms, pool saturation, PgBouncer behavior, and max_connections pressure.
CPU, memory, disk, temp files, checkpoints, buffers, and workload pressure.
Index design, index debt, reindexing, constraint indexes, and evidence-driven DDL.
Lock waits, deadlocks, blocking chains, idle transactions, and transaction hygiene.
Galera clustering, InnoDB and Aria internals, replication, optimizer behavior, and MariaDB operations notes.
InnoDB internals, replication, locking, query performance, and MySQL operations notes.
HNSW, IVFFlat, recall, embedding search, and production RAG performance notes.
Replica lag, WAL growth, failover readiness, hot standby behavior, and replication slots.
Query plans, EXPLAIN ANALYZE, planner regressions, pagination, joins, and statistics.
Wait statistics, tempdb, Query Store, Always On availability groups, and SQL Server operations notes.
Autovacuum, dead tuples, bloat, wraparound, MVCC, freeze age, and visibility.
PostgreSQL's 32-bit transaction IDs wrap around after roughly two billion transactions of visibility horizon. How freezing prevents it, how to monitor age(datfrozenxid), and how to dig out of the emergency.
Four hundred requests a minute, three temp tables each: three months later pg_attribute weighed 9 GB with six million dead tuples. Why per-request DDL churns the catalogs, and the patterns that stop it.
A bulk-load job set synchronous_commit = off 'just for the import', the setting leaked into the app config, and a host crash cost us three minutes of orders that had already reported commit success. Here is what each level actually…
The planner picked a nested loop that ran 400,000 times because n_distinct was off by a factor of 30. Raising one column's statistics target fixed the estimate — and the plan — in a single ANALYZE.
We flipped SERIALIZABLE on after an audit found a real race. Staging was calm for two weeks; production answered with a 40001 storm every time the batch window overlapped evening traffic.
The ticket said search was fast for admins and took nine seconds for tenants — same query, same table. The difference was a policy that never appeared in any SQL anyone had written.
One RLS policy with a memberships subquery turned our indexed tenant lookups into per-row nested loops overnight — p95 went from 9 ms to 1.4 seconds. Here's how we found it and the pattern that fixed it.
A decommissioned standby left its replication slot behind, and over one quiet weekend the slot pinned 214 GB of WAL until the primary ran out of disk and PANIC'd. Here is the mechanism, the monitoring queries, and the circuit breaker…
The 3 a.m. page was pg_wal at 100 percent on a healthy primary. The cause was a Debezium slot from a proof of concept eight weeks earlier, quietly pinning 380 GB of WAL nobody would ever read.
Plain REFRESH held ACCESS EXCLUSIVE for four minutes and queued every dashboard reader we had. CONCURRENTLY fixed the lock and quietly created a bloat problem — the full cost sheet, plus the rename-swap pattern I use instead.