How do transaction isolation levels differ?

Direct answer

What a strong answer covers

How it works

Isolation levels name which anomalies a transaction may see. Read uncommitted allows dirty reads; read committed prevents them but lets the same query return different rows later in the transaction; repeatable read freezes rows already read but may still allow phantoms in some engines; serializable guarantees the outcome equals some serial order and may abort a transaction to keep that promise. Engines implement these with locks or multi-version snapshots, so the same level behaves differently across PostgreSQL, MySQL, and SQL Server.

Example

A stock reservation may need a guarded update or serializable transaction to prevent two purchases from consuming the same last item. Under read committed, two transactions can both read stock = 1 and both decrement; a SELECT FOR UPDATE or an UPDATE ... WHERE stock > 0 that checks the affected row count closes the gap.

Common mistakes

• Assuming repeatable read prevents every anomaly including write skew.
• Raising the level globally instead of protecting the one invariant that needs it.
• Forgetting that serializable transactions can fail and must be retried by the application.

A useful answer structure

Answer from your own work.

Do not memorise a script: use only examples you can explain honestly in follow-up questions.