{
  "id": 3693913,
  "title": "MVCC Explained: Build Postgres-Style Snapshots in 100 Lines of TypeScript",
  "url": "https://urgent.news/2026/08/27/mvcc-explained-build-postgres-style-snapshots-in-100-lines-of",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-08-27T07:35:38.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/jatin510/mvcc-explained-build-postgres-style-snapshots-in-100-lines-of-typescript-37be"
  },
  "original_language": "en",
  "account": "PostgreSQL, MySQL/InnoDB, Oracle, and SQLite (in WAL mode) all employ a feature called Multi-Version Concurrency Control (MVCC) to enable readers and writers to coexist without interfering with one another. The MVCC mechanism in this article is built using about 100 lines of TypeScript and explained through the following steps:\n\n1. Understand that a database table is not a mutable array but a chain of versions.\n2. Recognize that updates and deletes are replaced by appending new versions, while the old version remains intact.\n3. Implement DELETE by marking the latest version as dead, allowing the old version to persist.\n4. Stamp every version with two transaction IDs, xmin and xmax, to record when the version was created and when it was deleted.\n5. Implement INSERT by appending a new version with an xmin equal to the current transaction ID and a null xmax.\n6. Implement DELETE by updating the xmax of the live version to the current transaction ID.\n7. Implement UPDATE by combining a DELETE and an INSERT operation.\n8. Understand that transactions are just an incrementing counter, functioning as transaction IDs and timestamps.\n9. Realize that reading uncommitted data can lead to dirty reads, which can be prevented by considering only committed transactions when determining visibility.\n10. Introduce a commit log (clog) to keep track of whether a transaction has committed, aborted, or is still running.\n11. Verify the MVCC mechanism by comparing the results of SELECT statements before and after executing UPDATE operations in a PostgreSQL database.",
  "summary": "Open two psql sessions. Session A: BEGIN ; DELETE FROM users ; -- deletes all 1 million rows -- don't commit yet Session B: SELECT count ( * ) FROM users ; -- count: 1000000 Session A deleted every row. Session B sees every row. Neither session is waiting on the other. No locks, no blocking, no errors. So... where are the rows? Deleted, or not? The answer is both , and by the end of this post…",
  "key_points": [
    "MVCC enables readers and writers to coexist without interference in databases.",
    "Updates and deletes are implemented by appending new versions while preserving old versions.",
    "DELETE is marked as dead, allowing old versions to persist in the database."
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}