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.
The fleet dashboard ran one greatest-n-per-group query against 2.1 billion status rows: 38 seconds on MySQL with the classic join-to-GROUP-BY idiom, 11 milliseconds on PostgreSQL after a LATERAL rewrite. The two engines were not disagreeing about speed — they were…
The weekly export concatenated each account's tags with GROUP_CONCAT, and for eleven months nobody noticed that MySQL was silently cutting the lists off at 1024 bytes — a warning, not an error, buried in a log nobody read. Field notes…
The retention job had to delete 41 million rows a month. The first attempt was a single DELETE: fifty minutes of lock waits on MySQL, then on PostgreSQL a nine-minute statement followed by an autovacuum storm that took the read…
The OOM killer took the primary at 14:22 and PostgreSQL was back in memory by 14:23 — but it refused connections until 15:01. In between it replayed 61 GB of WAL, single-threaded, against cold storage. Here is what drives that…
Our first planned switchover after adding logical replication broke the Debezium pipeline: the slot lived on the old primary, and the new primary knew nothing about it. PostgreSQL 17's failover slots sync the slot to the standby. The drill that…
A routine rolling restart of the application tier turned into twelve minutes of ERROR 1040: every app node reconnected at once, idle connections from the old processes had not timed out yet, and the DBA could not even get a…
The monthly finance report had run for two years without incident, right up until the month the data crossed an invisible line: its GROUP BY stopped fitting in memory, spilled to an on-disk temp table, and filled the 8 GB…
After the third 'the site felt slow around lunch' report in a month, we stopped arguing about whether it happened and turned on the slow query log properly. The first digest took eleven minutes to produce and named one query…
The kernel patch reboot took ninety seconds. The hangover took forty minutes: p99 latency eight times normal while InnoDB re-read its working set from disk, one cold page at a time. The fix had been compiled into the server the…
At 04:50 on a Saturday an ETL package left a transaction open for six hours, the log grew to 512 GB, and error 9002 stopped every write in the database. Here is how I find what is holding the log…