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.
A killed six-hour batch job once rolled back for nearly five hours, holding its locks the whole time. With accelerated database recovery the same class of kill returns the database in seconds — but the persisted version store becomes a…
We moved a 190-million-row nightly-rebuilt lookup table from InnoDB to Aria and cut the rebuild from 2 h 10 m to 34 minutes — until one kernel panic turned crash recovery into a 47-minute repair job.
A 09:20 deploy flipped a hot query from index seek to table scan and p95 latency went from 40 ms to 2.8 seconds. Query Store flagged the regression by 09:35, a forced plan held the line for two days, and…
The events table stalled at 4,100 inserts per second on a 96-core box with idle disks, and every waiter was queued on PAGELATCH_EX for the same page. Why ever-increasing keys funnel inserts into one latch queue, and what actually breaks…
CPU was at 34 percent, the disks were bored, and 380 sessions were queued on PAGELATCH_EX against page 2:1:1 in tempdb. Why one data file serializes allocation, how many files to add, and the version store case files alone will…
One statistics update at 9:14 AM recompiled a stored procedure against the biggest customer's parameters, and every small customer went from 50 ms to six seconds. The patterns, the fixes, and their honest costs.
Dump-and-restore means downtime. This is the dual-run playbook for migrating MySQL to PostgreSQL with CDC: initial snapshot, catch-up, a concrete cutover checklist, and a real rollback window.
Percona XtraBackup plus binary logs is still the workhorse recovery story for self-managed MySQL. These are field notes on the full/incremental cadence, prepare ordering, and the restore rehearsal that catches bad backups.
I run PostgreSQL for a living and I still tell some teams to stay on MySQL. Here are the cases where migrating is the wrong call, and a decision framework that beats database dogma.
Random UUIDs punish InnoDB's clustered index far harder than PostgreSQL's heap, but neither engine loves them. Here is the real damage model, and how UUIDv7 and ULID change the math.