MVCC: How to Explain It in an Interview (2026)

Multi‑Version Concurrency Control (MVCC) is a technique that lets a database serve a consistent view of data to each transaction without blocking writers. In plain terms, every write creates a new version of a row, and each transaction reads the version that was valid at the moment it started.

How MVCC Works Under the Hood

Version Chains

When a row is inserted, the database stores the data together with two hidden fields: a creation timestamp (or transaction ID) and a deletion timestamp. Subsequent updates append a new version to the same logical row, forming a chain:

A transaction that started at timestamp 103 will see v1 because v2 did not exist yet. A transaction that started at 108 will see v2 because v1 is marked deleted by TX 105.

Visibility Rules

• Read‑only transaction: picks the snapshot timestamp at start and reads the newest version whose creation timestamp ≤ snapshot and whose deletion timestamp > snapshot (or NULL).
• Read‑write transaction: behaves like a read‑only one for its reads, then writes new versions with its own transaction ID. Conflicts are detected when two concurrent transactions try to modify the same row – the later one aborts.

Garbage Collection (VACUUM)

Old versions that are no longer visible to any active transaction can be reclaimed. Systems run a background vacuum process that scans version chains and removes rows whose deletion timestamp is older than the oldest running transaction.

Trade‑offs of MVCC

In practice, systems like PostgreSQL, MySQL InnoDB, and many NoSQL stores adopt MVCC because the read‑heavy workloads typical of web applications benefit from non‑blocking reads. The cost shows up as larger tables and occasional pauses for vacuuming.

A Concrete Example

Imagine a ticket‑booking service. Two users, Alice and Bob, try to book the last seat at the same time.

1. Both start transactions at timestamp 200.
2. The seat row currently has version v1 (available) with creation = 150, deletion = NULL.
3. Alice updates the row to v2 (reserved) with creation = 201.
4. Bob, still seeing snapshot 200, also creates v3 (reserved) with creation = 202.
5. When the DB checks for conflicts, it sees that both Alice and Bob wrote the same row. The later transaction (Bob’s) is aborted, forcing Bob to retry.

The result: only one reservation persists, and the other user receives a clear “seat already taken” message.

Questions Interviewers Often Ask

When answering, keep the focus on the mechanism first, then discuss trade‑offs, and finish with a short example that ties back to the problem you solved in a past project. That narrative shows you can ground theory in real work.

60‑Second Spoken Answer

"Multi‑Version Concurrency Control, or MVCC, is a way databases keep a consistent view for each transaction by storing multiple versions of a row. When a transaction starts, it gets a snapshot timestamp and reads the newest version whose creation time is before that timestamp and whose delete time is after it. Writes don’t overwrite; they append a new version with the transaction’s ID. This means readers never block writers, which is great for read‑heavy workloads. The downside is extra storage for old versions and the need for a background vacuum to clean them up, especially if you have long‑running transactions. For example, in a ticket‑booking system, two users might try to reserve the last seat simultaneously; MVCC lets the first write succeed while the second detects a conflict and rolls back. Interviewers usually ask about snapshot isolation, the impact of long‑running transactions, and how vacuum works."

How to Practice This

1. Write the answer on paper – keep it under 90 seconds, then time yourself.
2. Run a mock interview using Call Assistant to capture your spoken answer and get instant feedback on phrasing and flow.
3. Create a version‑chain diagram for a simple table, then explain the visibility rules out loud to solidify the mental model.

---

FAQ

• What is the main advantage of MVCC over locking? MVCC allows reads to proceed without waiting for writes, reducing contention and improving throughput for read‑heavy workloads.

• Does MVCC guarantee serializable isolation? By itself it provides snapshot isolation; achieving full serializability requires additional checks such as write‑conflict detection or serializable snapshot isolation extensions.

• How often should a database run vacuum? It depends on workload; most systems trigger vacuum when the amount of dead tuples exceeds a configurable threshold or when long‑running transactions are detected.

• Can MVCC be used in distributed databases? Yes, but the implementation details differ. Distributed systems often combine MVCC with logical timestamps or vector clocks to maintain consistency across nodes.