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.
You partitioned the table by month and the queries got no faster, because EXPLAIN still lists all 48 partitions in the plan. Here is why pruning fails and the rewrites that bring it back.
MySQL grew failover tooling around topology repair; PostgreSQL grew it around consensus and leases. Comparing orchestrator and group replication with Patroni and repmgr, honestly.
EXPLAIN tells you which plan MySQL chose; optimizer_trace tells you which plans it rejected and why. Per-session capture, reading considered_execution_plans, cost numbers, truncation traps, and a worked wrong-index case.
When the MySQL optimizer guesses wrong by a factor of a thousand, plans collapse. Column histograms fix skewed, non-indexed estimates, if you know when they are ignored.
InnoDB hides old row versions in undo logs and reclaims space with rebuilds; PostgreSQL keeps dead tuples in the heap and reclaims them with VACUUM. Two different bloat models, two maintenance disciplines.
ALGORITHM=INSTANT finishes in milliseconds; INPLACE rewrites every row; COPY blocks writers. The 64 row-version limit, metadata locks, progress monitoring, and when gh-ost still wins.
Multi-source replication lets one replica fan in from many primaries with FOR CHANNEL syntax — but there is no conflict detection and no last-write-wins. Setup, per-channel monitoring, GTID bookkeeping, and when a pipeline beats fan-in.
Your MySQL dashboards encode years of operational knowledge, and none of them work after a PostgreSQL migration. This is the translation table I wish I had: every major MySQL signal mapped to its PostgreSQL equivalent.
The processlist fills with 'Waiting for table metadata lock' and the application stops, but the cause is a session doing nothing at all. A field guide to the MDL pileup, the kill-or-wait decision, and the guardrails that make it rare.
MySQL memory is not just the buffer pool. This guide maps global versus per-session allocations, shows how to interrogate performance_schema memory instrumentation, and walks through a real OOM-kill postmortem workflow.