Transaction Isolation Levels — Read Uncommitted to Serializable
Fast recall
Quick revision
Core answer
Whether you understand the specific anomalies each level prevents, can identify which level your application needs, and know the performance trade-offs.
Assuming Repeatable Read in PostgreSQL works the same as in MySQL — PostgreSQL's Repeatable Read actually prevents phantom reads (it uses true snapshot isolation), while MySQL's uses gap locking with different edge cases.
Explain write skew — the anomaly that only Serializable prevents — where two transactions each read the same data, make valid decisions based on their snapshots, and each write to a different row, but the combined result violates a business invariant.
Interview-ready guide
Interview answer
Isolation levels control how much a transaction can see of other concurrent transactions' changes. The four levels each prevent a different class of anomaly, and the higher the isolation, the more it costs in throughput.
Read Committed — the practical default
- Most databases (PostgreSQL, Oracle) default to Read Committed — a transaction sees only data committed before each statement runs, which protects against dirty reads but allows non-repeatable reads: reading the same row twice may return different values if another transaction commits in between
- This is the right default for most OLTP workloads — the anomalies it allows are uncommon enough that the cost of stronger isolation is not justified
Repeatable Read — same snapshot for the whole transaction
- A transaction holds a consistent snapshot as of when it began — which means reading the same row twice always returns the same value, even if another transaction commits a change in between
- The implementation trap: PostgreSQL's Repeatable Read also prevents phantom reads because MVCC handles it without gap locks; MySQL's Repeatable Read does not prevent phantoms in all edge cases — this is the most common cross-database portability mistake
Serializable — the only level that prevents write skew
- Write skew is the anomaly where two transactions each read overlapping data, make independent decisions based on it, and both commit — leaving a state that no serial execution could have produced
- Classic example: two on-call doctors each check "is anyone else on call?" see yes, and both go off call — neither violated any row-level constraint, but the combined result is invalid; only Serializable prevents this
Read Uncommitted — almost never appropriate
- Allows reading uncommitted changes from other transactions — useful only for rough approximate counts on non-critical data where a small error is acceptable and blocking is not
In interviews: know which level prevents which anomaly, know the PostgreSQL vs MySQL default difference, and know write skew as the Serializable-only anomaly.
Transaction Isolation Levels — Read Uncommitted to Serializable
Direct Answer
SQL defines four transaction isolation levels that control what a transaction can see of other transactions' concurrent changes. read uncommitted allows dirty reads. read committed (PostgreSQL default) prevents dirty reads but allows non-repeatable reads. repeatable read (MySQL InnoDB default) additionally prevents non-repeatable reads using MVCC snapshots. serializable prevents all anomalies including phantoms by making transactions behave as if they ran sequentially.
Common Mistakes & Pitfalls
Assuming Repeatable Read in PostgreSQL works the same as in MySQL — PostgreSQL's Repeatable Read actually prevents phantom reads (it uses true snapshot isolation), while MySQL's uses gap locking with different edge cases.
Check your understanding
Answer these without looking back at the article.
- What is write skew and how does Serializable isolation prevent it?
- How does PostgreSQL's snapshot isolation differ from MySQL's Repeatable Read?
- When would you choose Serializable isolation over Read Committed?
Related interview prep categories
2Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.