Isolation Anomaly

The problem

Every application developer picks a database isolation level, the setting that decides how much two simultaneous operations may interfere. Almost everyone keeps the default, and almost nobody can say what it protects them from. The failure modes are taught as a list of names, dirty read, non-repeatable read, phantom, that people recite in interviews and rarely understand.

The most dangerous failure isn't on that list. In write skew, two transactions read the same data, each checks a rule ("someone else is still on call, so I can go off call"), and each writes a different row. Nothing collides, both go through, and the rule is broken. This is how on-call rosters empty and rooms get double-booked. Snapshot isolation doesn't prevent it, and it is what most defaults amount to. Worse, the level names mean different things in different databases. Oracle's "SERIALIZABLE" still allows write skew.

What I built

Real databases came first

A developer might make a production decision from what this tool shows, so I couldn't build the simulator from what I believed about databases. Before the simulator existed, I wrote a harness that starts real PostgreSQL, MySQL, SQL Server and Oracle in containers and runs every schedule against them. It records every value read, every error code, where each transaction waited and whether it finished. Those 220 recordings are the answer key. When the simulator and a recording disagree, the simulator is wrong.

One engine, five rule files

There is one simulator. Each database is a file of rules: what each level name really means, when locks are taken, what conflicts and which error code comes back. The comparison between databases is only fair if the machinery is shared, and a database expert can review a rule file without reading my code. Every rule cites the vendor's documentation, and the deploy fails if a citation is missing.

A separate checker names the anomaly

The code that spots an anomaly shares nothing with the simulator. It reads the finished run and checks each anomaly against its published definition. A checker built on the simulator's assumptions would approve the simulator's bugs. Every scenario is tested both ways: the anomaly must appear at levels that allow it, and must not appear at levels that prevent it.

The tool refuses when it can't know

SQL Server picks which transaction to kill in a deadlock by a cost estimate, so the same schedule can lose a different transaction at different levels. I didn't guess. That rule is marked as not modelled, and the tool refuses the run and says why. A test checks that each refusal matches an actual deadlock in the recordings. The harness also caught one deadlock rule I had written wrong, which is why I built it first.

The schedule reads like sheet music

Transactions sit on parallel staves, like a musical score, with a bar line at each step. Reading down a bar line shows what happened at the same moment. You can drag operations to reorder them and the run updates. One red mark lands on the exact step where the anomaly became unavoidable, with a one-line explanation generated from the run. A matrix runs the same schedule on all five rule files at every level.

Result

Isolation Anomaly is live and public, in English and Indonesian, as a fully static site. It models five engines: PostgreSQL 16, MySQL 8.4, SQL Server 2022, SQL Server 2022 with snapshot reads switched on, and Oracle 23ai. Eleven scenarios frame the stakes, such as an on-call roster for write skew and a bank transfer for read skew. You can also build your own schedule and share it by link. I built it alone over two days in August 2026.