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 nightly loader survived four MariaDB upgrades and died on the fifth with 'Incorrect integer value'. The default sql_mode had quietly changed in 10.2.4, and this one legacy box had skipped straight past the release where the warning would have…
We turned on server_audit with QUERY events on a Friday, logged 41 GB over the weekend, filled the disk, and added 30% to write-path p99. The compliant configuration we ended up with logs 2 GB a day and nobody notices…
Our order numbers lived on AUTO_INCREMENT until a second write node appeared and the increment-and-offset trick started to creak. Sequences gave us controlled, cacheable, gap-tolerant numbers — here is the full cost sheet.
The telemetry table had monthly partitions plus a MAXVALUE catch-all, and a cron job that added next month's partition — until the cron host was decommissioned and nobody noticed for eleven months. 900 million rows sat in pmax, and REORGANIZE…
One reporting replica pulled from three primaries for eight months without a hiccup — until the catalog primary failed over and the replica started applying the same transactions twice. Every server involved shared gtid_domain_id 0. Here is the full autopsy.
MariaDB 10.6 goes end of life in July 2026, so we rehearsed the jump to 11.4 LTS on a restored backup. The upgrade itself took eleven minutes; finding the removed config variable, the renamed client tools, and the one query…
Users updated their profiles, hit save, reloaded — and saw the old values. The write went to Galera node A, the read to node B, and node B had not applied the writeset yet. wsrep_sync_wait was 0, the default. The…
An ORM migration ran DROP TABLE tenant_usage at 11:20 on a Tuesday. Our delayed replica, six hours behind by configuration, still had the table and every write from that morning. The recovery took forty minutes and cost zero data. Here…
The report query took 40 ms every day except Mondays, when it took 41 seconds. EXPLAIN showed the identical plan both days. ANALYZE showed the truth: one node estimated 900 rows and actually read 1.8 million of them on Monday's…
A staging table variable holding 180,000 rows was being planned as one row, and the join strategy built on that estimate took eleven minutes. Swapping one character — @ to # — took it to nine seconds. The actual differences,…