Archivedatabases
MVCC: Readers Never Block Writers
Keep multiple versions and hand each transaction a snapshot. The cost is version cleanup and write conflicts.
- Published
- Reading time
- 1 min read
Multi-version concurrency control stores several versions of a row and lets each transaction read from a consistent snapshot. Readers do not take locks; writers create new versions.
The mechanics
- Each transaction gets a snapshot (timestamp or transaction ID).
- A read returns the newest version visible to that snapshot.
- A write creates a new version tagged with the writer's ID.
- Visibility rules decide which versions a transaction sees.
Postgres keeps old versions in the heap and vacuums them; MySQL/InnoDB keeps undo logs and a rollback pointer.
The costs
- Storage and cleanup: dead versions accumulate; vacuum or purge must keep up.
- Write conflicts: two transactions updating the same row — one must abort under serializable isolation.
- Index bloat: indexes point at versions that no longer matter.
The benefit
Long-running reads and reports do not block OLTP writes, which is why MVCC is the default for general-purpose databases.
Takeaway: MVCC buys concurrency with garbage collection. If cleanup lags, you get bloat and eventual latency cliffs, not correctness bugs.