MVCC
/em-vee-see-see/ · noun · Development · Origin: 1981
Definitions
Multi-Version Concurrency Control — a technique where the database maintains multiple versions of each row so that readers see a consistent snapshot without blocking writers, and writers don't block readers. MVCC eliminates most read-write lock contention and is used by PostgreSQL, Oracle, MySQL/InnoDB, and most modern relational databases.
In plain English: A database trick where reading and writing can happen at the same time without interfering, because the database keeps multiple versions of the data.
Example: Thanks to MVCC, the analytics dashboard can run heavy queries against consistent snapshots without blocking the OLTP workload on the same database.
Etymology
- 1978
- David P. Reed described the concept of multiversion concurrency in his MIT dissertation, proposing that databases maintain multiple versions of data to avoid locking.
- 1981
- The term 'Multi-Version Concurrency Control' was formalized. Reed's approach allowed readers to access consistent snapshots without blocking writers.
- 1984
- PostgreSQL's predecessor, Postgres, was designed at UC Berkeley with MVCC as a core feature, making it one of the first systems to implement the model practically.
- 2000s-Present
- MVCC became the dominant concurrency control mechanism in relational databases. PostgreSQL, Oracle, MySQL/InnoDB, and SQL Server all use variants of MVCC.
Origin Story
The Time Machine Inside Your Database
Multi-Version Concurrency Control (MVCC) is a database technique that allows multiple transactions to access the same data simultaneously without blocking each other, by maintaining multiple versions of each row. The concept was first described by Philip Bernstein and Nathan Goodman in a 1981 paper, 'Concurrency Control in Distributed Database Systems.' Their insight was radical: instead of locking rows to prevent conflicts (which creates bottlenecks), the database could keep old versions of data around so that readers see a consistent snapshot while writers create new versions. This means a long-running report can read a stable view of the data even as other transactions are actively modifying it. PostgreSQL adopted MVCC as its core concurrency model from the very beginning of the project (originally called Postgres, created by Michael Stonebraker at UC Berkeley in 1986). Oracle independently implemented a similar approach using its 'undo segments.' MySQL's InnoDB engine also uses MVCC. The trade-off is that old row versions accumulate and must be periodically cleaned up, a process PostgreSQL calls 'vacuuming.' Despite this maintenance overhead, MVCC's ability to provide snapshot isolation without read locks has made it the dominant concurrency control strategy in modern databases.
Coined by: Philip Bernstein and Nathan Goodman
Context: Described in a 1981 paper on concurrency control for distributed database systems.
Fun fact: PostgreSQL's VACUUM process, which cleans up old MVCC row versions, was historically so disruptive that it earned the nickname 'the VACUUM problem.' The introduction of autovacuum in PostgreSQL 8.1 (2005) was considered one of the most important usability improvements in the database's history.