A consistent frozen view
Under snapshot isolation, a transaction reads from a snapshot taken at its start. Every read returns data as it stood at that instant, unaffected by concurrent commits. Writes are checked for conflicts only against other writers.
First committer wins
Two transactions may both write, but they cannot both modify the same row. The database enforces a first committer wins rule.
- If two transactions update the same row, the first to commit succeeds.
- The second sees a write write conflict at commit and aborts.
This prevents lost updates on a single row, which weaker levels allow.
The write skew gap
Snapshot isolation is strong but not serializable. Its famous hole is write skew, where two transactions read an overlapping set, then each writes a different row based on what it read.
- Each transaction is valid against its own snapshot.
- Together they violate an invariant neither could see being broken.
A classic example is two on call doctors each leaving a shift because each sees the other still on duty, ending with nobody covering.
Key idea
Snapshot isolation gives every transaction a stable read view and blocks lost updates, but it still permits write skew because conflicting writes touch different rows.