[1] Without concurrency control, if someone is reading from a database at the same time as someone else is writing to it, it is possible that the reader will see a half-written or inconsistent piece of data.
MVCC aims at solving the problem by keeping multiple copies of each data item.
In some cases, a process to periodically sweep through and delete the obsolete versions is implemented.
This is often a stop-the-world process that traverses a whole table and rewrites it with the last version of each data item.
The main inherent limitation of this latter approach is that when there are update-intensive workloads, the undo log part runs out of space and then transactions are aborted as they cannot be given their snapshot.
A Write cannot complete if there are other outstanding transactions with an earlier Read Timestamp (RTS) to the same object.
[2] The drawback to this system is the cost of storing multiple versions of objects in the database.
MVCC is particularly adept at implementing true snapshot isolation, something which other methods of concurrency control frequently do either incompletely or with high performance costs.
Bernstein and Goodman's paper cites a 1978 dissertation[4] by David P. Reed which quite clearly describes MVCC and claims it as an original work.
The first shipping, commercial database software product featuring MVCC was VAX Rdb/ELN, released in 1984,[5] and created at Digital Equipment Corporation by Jim Starkey.