What is Transaction Isolation Level?
Isolation levels and anomalies, told as a story about a packer and a driver touching the same box at once.
A packer and a driver touch the same box at the same time.When two people touch one box at once, each sees a different count.
With no rules for simultaneous work, three kinds of read errors happen.Dirty reads, non-repeatable reads, and phantom reads.
Isolation level is the rule for how strictly to keep simultaneous work apart.The stricter the rule, the safer the numbers, but work can slow down.
The SQL standard defines four isolation levels.Serializable is the strictest.
Serializable is safest, but the next person may wait longer than at lower levels.So pick the isolation level that fits the safety and speed the work needs.
Isolation level decides, when several people touch the same data at once, how much of each other's work they can see.
Transaction isolation levels — Read Uncommitted, Read Committed, Repeatable Read, Serializable — allow progressively fewer anomalies (dirty read, non-repeatable read, phantom read) as they get stricter. Stronger isolation means higher consistency but can lower concurrent throughput.
When grown-ups say it
- Dirty Read
- Seeing a value that isn't confirmed yet. By the SQL standard, allowed only at read uncommitted.
- Non-repeatable Read
- Re-reading the same thing gives a different value. Blocked from repeatable read onward.
- Phantom Read
- A row that wasn't there shows up on re-query. By the SQL standard, fully blocked at serializable. Some products, like PostgreSQL, block it at repeatable read too.
- Serializable
- The level that makes simultaneous work look done one at a time. Strictest, and usually the slowest under concurrent work.
- ACID
- The four promises a receipt keeps. Isolation is one of the four. → the four promises a receipt keeps
- Concurrency Control
- How isolation levels actually get enforced. Implemented with locks or MVCC. → the no-collision rule
- CAP Theorem
- A trade-off story from the SRE field. Covers the limits of consistency itself in distributed settings. → the CAP theorem
- Eventual Consistency
- Copies differ for now, but eventually match. A different distributed-systems compromise from isolation levels. → eventual consistency