Jepsen: MySQL 8.0.34

Original Article ↗ Hacker News Discussion ↗

Jepsen’s analysis of MySQL 8.0.34 has renewed scrutiny of the database’s transactional guarantees, showing that its default “repeatable read” isolation can still produce surprising anomalies—even on a single node—and that vendors and users often misunderstand what safety level they’re actually getting. Commenters contrast MySQL with PostgreSQL and other systems on performance, replication, operational complexity, and isolation semantics, with many arguing that serializable isolation should be the default while acknowledging its performance costs. The thread highlights how real-world systems can appear to work “well enough” atop weaker or poorly documented consistency models, and how hard it is for typical developers to reason correctly about isolation levels.

Why start new projects on MySQL?

  • Many use MySQL because they already know it, can troubleshoot it, and it “works well enough” for typical workloads.
  • It scales sufficiently for most companies; more extreme cases can use tools like Vitess.
  • Historically offered pluggable engines and easy replication; perceived as simpler to operate and good for read-heavy apps.
  • Some find the CLI and tooling more “developer-friendly” than alternatives.

MySQL vs PostgreSQL: features and operations

  • PostgreSQL is praised for a saner SQL dialect, richer features (JSONB, partial/expression indexes), and strong ecosystem.
  • MySQL is argued to be operationally simpler: easier upgrades, long‑standing logical replication, less painful autovacuum‑style tuning.
  • Some claim MySQL’s MVCC and threading model are technically stronger than PostgreSQL’s process‑per‑connection plus vacuuming, though others contest scaling claims.
  • Postgres query planner is more advanced but can unpredictably choose bad plans without easy forcing; MySQL’s more limited planner is seen as more predictable in emergencies.

Isolation levels, correctness, and defaults

  • The thread centers on MySQL’s “Repeatable Read” not matching the formal model and producing anomalies even on a single node.
  • Several argue default isolation should be SERIALIZABLE because most developers don’t understand isolation; weaker levels produce subtle, hard‑to‑debug bugs.
  • Others stress SERIALIZABLE’s performance cost and frequent transaction retries, advocating it only when strictly required.
  • Some propose only two meaningful levels for most apps: READ COMMITTED and SERIALIZABLE; anything in between is seen as confusing “no man’s land.”
  • Snapshot isolation is viewed as valuable for read‑only queries.

Developer practices and locking

  • Many commenters say developers rarely think about isolation or consistency at all; they just accept defaults.
  • SELECT … FOR UPDATE and explicit locking can “fix” anomalies but at the cost of performance, lock contention, and potential deadlocks.
  • Long‑lived or large transactions are highlighted as major performance and scaling risks under MVCC.

MySQL variants and broader implications

  • MariaDB is reported to show the same anomaly classes as MySQL, even in single‑node tests.
  • Aurora MySQL largely preserves MySQL/InnoDB semantics, with some cluster‑specific quirks around shared storage and purge.
  • Commenters find it striking how many “practically working” systems are built atop engines with such observable consistency artifacts.