{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreidqjgyuqbtihepwjvbvnfd36p46joruuydto3tijq3rt7sxxea7o4",
    "uri": "at://did:plc:5sgu76a53rz3n6unbykmovqy/app.bsky.feed.post/3mloh6mcii2x2"
  },
  "description": "Multi-Version Concurrency Control (MVCC) is a concurrency mechanism in which writers do not block readers and readers do not block writers. Instead of locking rows for the duration of a transaction, the database keeps multiple versions of each row, and each transaction sees a consistent snapshot of the data as of its start time.\n\n\nHow it works\n\nEvery row carries internal metadata about which transaction created it and (if applicable) which transaction deleted or updated it. A transaction sees a ",
  "path": "/engineering-glossary/mvcc-multi-version-concurrency/",
  "publishedAt": "2026-05-12T18:46:30.000Z",
  "site": "https://sahilkapoor.com",
  "tags": [
    "PostgreSQL",
    "MySQL",
    "ACID",
    "SQL",
    "OLTP"
  ],
  "textContent": "**Multi-Version Concurrency Control (MVCC)** is a concurrency mechanism in which writers do not block readers and readers do not block writers. Instead of locking rows for the duration of a transaction, the database keeps multiple versions of each row, and each transaction sees a consistent snapshot of the data as of its start time.\n\n## How it works\n\nEvery row carries internal metadata about which transaction created it and (if applicable) which transaction deleted or updated it. A transaction sees a row only if it was created by a committed transaction visible at the transaction's snapshot, and not yet deleted by another visible transaction. Updates create new versions rather than modifying in place; deletes mark the row as ended at the deleting transaction.\n\n## Implications\n\n  * **High read concurrency.** Reads never wait on writes and vice versa.\n  * **Garbage collection.** Dead row versions accumulate and must be reclaimed by a background process (PostgreSQL's `VACUUM`, MySQL InnoDB's purge thread).\n  * **Long transactions are expensive.** They prevent garbage collection of any row version they might read, bloating the database.\n  * **Predictable read paths.** Snapshot isolation makes reasoning about query results within a transaction easier.\n\n\n\n## Where MVCC is used\n\n  * PostgreSQL (the classic example), Oracle, MySQL InnoDB, SQL Server (snapshot isolation), CockroachDB, Spanner, FoundationDB\n\n\n\n🔗\n\n**Related Terms**\nPostgreSQL, MySQL, ACID, SQL, OLTP.",
  "title": "MVCC",
  "updatedAt": "2026-05-13T19:14:38.512Z"
}