Skip to content

Start here ​

Four questions, four links. Pick the ones that apply to you and go.

Which track: PostgreSQL or MySQL? ​

Read the track for the engine you already work with. Transactions look reasonable in the abstract and get strange in the specifics, and the specifics are what your production database will hand you at 3am.

If you're undecided, or you're learning this topic rather than shipping on a particular stack, start with PostgreSQL. Its snapshot model makes the isolation lessons visible: plain SELECTs use statement snapshots at READ COMMITTED and a stable transaction snapshot at REPEATABLE READ, plus their own writes. The anomalies show up as differences between what two sessions see. Once that clicks, the MySQL track teaches you the contrasts: current reads that use different visibility from consistent SELECTs and locking under different conditions. These examples do not compare deadlock rates. The other track is always one click away in the nav.

Where do I jump in? ​

Three readers, three doors.

The eight chapters in the sidebar run in order, so wherever you enter, forward is the way out.

How do I run it myself? ​

Clone the repo and bring up the databases to replay Scenarios on their named engines. --step pauses before statements; reference-only material has no local replay. The notification example runs psql inside the Compose container: run it locally.

Why trust any of this? ​

Scenarios assert particular runs on their own engine. Shared YAML also has independent Python-driver checks; TypeScript client code does not. Broader explanations use exact manual support or marked derivations. CI can reuse committed evidence for prose-only changes, so a green build does not mean every sentence was executed. The evidence limits are documented in how this site works.

MIT Licensed · Every transcript on this site was generated by a real database run against MySQL 8.4.11 and PostgreSQL 18.6 at 8fa27b8; shared YAML has an independent psycopg/PyMySQL check.