Isolation
Isolation is the "I" in ACID - it governs how concurrent transactions interact with each other in a database.
Nov 16, 2025
Isolation ensures that concurrent transactions don’t interfere with each other. Each transaction should execute as if it’s the only one running on the database.
Why it matters: Without isolation, system will face problems ike:
- Dirty reads: reading uncommitted data from another transaction
- Non repeatable reads: same query returns different results within one transaction
- Phantom reads: new rows appear between queries in the same transaction
Imagine you have £1000 in your account. Two transactions happen simultaneously:
- Transaction A: You withdraw £100 at an ATM
- Transaction B: Your paycheck of £2000 deposits
Without proper isolation, Transaction B might read your balance (£1000) while Transaction A is updating it, leading to lost updates. With isolation, each transaction completes independently.
Isolation levels (from weakest to strongest):
- Read Uncommitted: No isolation, allows dirty reads
- Read Committed: Can’t read uncommitted data (most common default), but allows non-repeatable reads
- Repeatable Read: Same reads return same results, but allows new rows
- Serializable: Complete isolation, as if transactions ran sequentially
Higher isolation = better consistency but lower performance. Most databases default to Read Committed as a practical middle ground.