/ˌɛm viː siː ˈsiː/
n. — "Database sorcery keeping readers blissfully ignorant of writers' mayhem."
MVCC (Multi-Version Concurrency Control) stores multiple temporal versions of each database row, letting readers grab consistent snapshots without blocking writers—who append fresh versions instead of overwriting. Unlike 2PL locking wars, transactions see "their" reality via timestamps/transaction IDs, with garbage collection culling ancient corpses once safe.
Key characteristics and concepts include:
- Append-only updates birth new row versions; readers self-select via xmin/xmax or visibility maps.
- Snapshot isolation: each txn sees database as-of-its-start, dodging dirty/non-repeatable reads.
- Write skew possible (lost updates), vacuuming/autovacuum prunes dead tuples bloating tables.
- Zero reader-writer blocking, but storage bloat demands periodic cleanup unlike lock-free queues.
In PostgreSQL workflow, SELECT grabs xmin-snapshot → concurrent UPDATE creates xmax=new_version → SELECT still sees old → VACUUM reclaims post-txn.
Intuition anchor: picture MVCC as time-traveling databases where every query warps to txn-birth snapshot, writers scribble parallel timelines—CouchDB revision trees git-merge conflicts while PostgreSQL VACUUMs zombie rows.