// the find
ept/hermitage
What are the differences between the transaction isolation levels in databases? This is a suite of test cases which differentiate isolation levels.
A manual test suite, originally built by Martin Kleppmann as research for Designing Data-Intensive Applications, that pins down exactly which concurrency anomalies (G0, G1a/b/c, OTV, PMP, P4, G-single, G2) each isolation level in Postgres, MySQL/InnoDB, Oracle, SQL Server, FoundationDB, CockroachDB, YugabyteDB, and Memgraph actually prevents. It's for anyone picking an isolation level who wants ground truth instead of vendor docs.
Uses Adya's formal anomaly definitions instead of the ANSI SQL isolation levels, which are famously vague and known to be flawed — so the comparisons are precise, not hand-wavy. The results table punctures a lot of assumptions: Oracle's 'serializable' is actually snapshot isolation, and MySQL's default 'repeatable read' is monotonic atomic view, not true repeatable read. Each database gets its own file (postgres.md, mysql.md, etc.) with copy-pasteable SQL split across labeled transactions, so you can reproduce every anomaly yourself in a few terminal windows rather than trusting the table.
Tests are executed by hand — there's no automation or CI, so this isn't something you can drop into a pipeline to catch a DB vendor changing default behavior across a version bump; it's a one-time educational exercise, not a regression suite. It's really a pile of markdown + SQL, not a library — if you want a reusable test harness you have to build one yourself, and the project explicitly tells you to fork elsewhere rather than contribute new database ports (VeloxDB's port lives in a separate repo). The core content is effectively frozen since the 2014 research; anyone relying on it for a DB not already listed, or a newer version of a listed one, is on their own to re-verify.