Notes for the problems that show up after launch: bad plans, awkward migrations, index debt, vacuum pressure, replica lag, and the small decisions that make PostgreSQL easier to operate.
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 skewed data.
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 fix is one variable; the cost model is the hard part.
A well-meaning engineer created forty-one indexes straight from dm_db_missing_index_details. Write latency doubled, three of the new indexes were never read once, and twelve were duplicates of each other with different column order. The DMV is a hint engine, not a design tool.
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 is the full setup and its sharp edges.
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 shown up.
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.
The storage team kept reporting a write burst every sixty seconds, and the database kept getting blamed for being badly written. It was the classic checkpoint doing exactly what recovery interval told it to do. How checkpoints actually schedule, and the two-line fix.
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, version by version, with the folklore removed.
Every ninety seconds the whole Galera cluster froze for two to four seconds, and the slow query log was empty. wsrep_flow_control_paused was climbing because one node applied writesets slower than the cluster delivered them. Here is the full diagnosis.
One tenant held 60% of a 480-million-row events table and the optimizer kept planning for a world that did not exist. MariaDB's engine-independent histograms fixed it — here is how they are stored, collected, and when they lie.
Error 824 at 03:12 on a Sunday: a torn page in the order history table, 40,000 orders unreadable, and a restore that would cost six hours of data. What CHECKDB actually checks, how to run it on a busy box, and the repair decision tree I follow before touching REPAIR_ALLOW_DATA_LOSS.
The same ALTER TABLE ADD COLUMN finished in 120 milliseconds on staging and ran for nearly four hours in production. The difference was not the table, the data, or the hardware — it was the MariaDB version and its instant-DDL capabilities.