Multi-Version Concurrency Control (MVCC)

• MVCC is a concurrency control protocol that maintains multiple data versions to enable non-blocking reads and minimize transaction aborts.
• It employs algorithms like MVTO, SSN, and Bohm to ensure serializability by validating dependency graphs and optimizing version visibility.
• MVCC underpins modern DBMS, HTAP systems, and blockchains, with ongoing research in decentralized timestamping, garbage collection, and performance optimizations.

Multi-Version Concurrency Control (MVCC) is a family of concurrency control protocols for transactional systems, enabling non-blocking reads and reducing transaction aborts by maintaining multiple versions of data objects. In MVCC, each update generates a new version, which is stored along with metadata such as commit timestamps. Transactions select versions based on protocol-specific rules (e.g., snapshot isolation, serializability), and correctness is established through dependency graphs or exclusion criteria that prevent undesirable schedules and anomalies. MVCC has become the prevailing choice for modern database management systems, software transactional memory (STM), persistent key-value maps, hybrid OLTP/OLAP platforms, and permissioned blockchains, and has inspired several formal models, optimization protocols, scalable implementations, and verification techniques.

1. Formal MVCC Models and Dependency Graphs

MVCC protocols are fundamentally defined via histories where each committed write creates a distinct version per object, identified by a logical timestamp (e.g., commit time, serialization order, or epoch index). A transaction’s read set selects for each object the version whose timestamp is maximal but less than or equal to its assigned snapshot time. This ensures that transactions observe a consistent view, possibly diverging from the latest value to tolerate concurrent writers.

Correctness criteria in MVCC are formalized through serialization graphs (SG, DSG, or multiversion conflict graphs) in which transactions are represented as nodes and dependencies (read-write, write-read/anti, write-write) form edges. Serializability is achieved if the graph is acyclic. Variants include:

• Conflict-serializability: The graph of classical rw/wr/ww conflicts must be acyclic (Kumar et al., 2015).
• Multiversion opacity (mvc-opacity): A history is mvc-opaque if it is valid (no reads from uncommitted writes) and admits a sequentialization preserving real-time order and multiversion conflicts (commit-read, read-commit, commit-commit) (Kumar et al., 2015).
• View-serializability: More permissive; schedules are valid if they are view-equivalent to a serial single-version schedule, but deciding it is NP-complete (Vandevoort et al., 2024).

Under key isolation levels (Read Committed, SI, SSI), formal results show that the sets of robust transaction schedules coincide for conflict- and view-robustness, i.e., no more sets become robust by switching from conflict- to view-serializability (Vandevoort et al., 2024).

2. Core MVCC Algorithms and Protocols

A. MVTO (Timestamp-Based MVCC for STM)

MVTO assigns each transaction a unique timestamp and for each write produces a new version with that timestamp. Reads select the largest committed version with timestamp less than the current transaction’s. At commit, the algorithm validates for each written object whether any intervening read conflicts exist (“no j < i < k” for read by k on previous version j before commit by i). MVTO guarantees opacity (every transaction, even aborted ones, sees a consistent state in a real-time-respecting total order) and mv-permissiveness (read-only transactions never abort) (Kumar et al., 2013).

B. Serial Safety Net (SSN) and Extended Serial Safety Net (ESSN)

SSN overlays serializability on weaker CC schemes by tracking local predecessor/successor watermarks for each transaction and version. At commit, a transaction passes an exclusion criterion: $\pi(T) > \eta(T)$ (SSN) or more generally $\pi(T) > \xi(T)$ (ESSN), where $\pi$ is the lowest stamp among back-edge dependencies and $\eta/\xi$ is the highest among forward dependencies. ESSN strictly subsumes SSN and reduces false aborts, especially for long, read-mostly transactions (Kitazawa et al., 28 Nov 2025Wang et al., 2016).

C. Bohm (Pre-Planned Pessimistic Serializable MVCC)

Bohm decouples concurrency control from execution. In CC phase, the global serialization order is pre-determined and all versions/reads are planned in timestamp order. Execution phase populates the version placeholders. Bohm guarantees reads never block writes, and avoids any read-tracking or commit-time validation (Faleiro et al., 2014).

D. MV3C (Graph-Based Partial Repair)

MV3C represents transactions as dependency graphs of predicates. Validation scans for conflicts, and partial re-execution is performed only on invalid graph subcomponents. This avoids full abort-and-restart overhead under high contention, maximizing reuse and throughput (Dashti et al., 2016).

3. MVCC in Practice: Garbage Collection, Scalability, Optimizations

A. Garbage Collection

Garbage collection is essential for MVCC to reclaim obsolete versions. Protocols attach successor links (nts), track live transactions, and delete versions whose timestamp intervals lack any active readers. Safe GC maintains the property that for every live transaction, its visible version is preserved (1305.66241904.03700).

B. Decentralization and Distributed MVCC

Classic centralized timestamp allocation for MVCC can bottleneck parallel systems. ViCC replaces centralized clocking with decentralized negotiation of visibility, anti-dependency tables, and visitor lists, supporting fully decentralized serializability (SV), snapshot isolation (PostSI), and consistent visibility (CV). This approach yields near-linear scaling with multi-core and MPP platforms (Zhou et al., 2017).

C. Lock-Free and High-Performance Data Structures

Lock-free range query maps (EEMARQ) retain multiple node versions linked via backward pointers and use atomic global timestamps and version-based epoch reclamation for memory management. Linearizability proofs rely on well-defined per-operation linearization points associated with timestamp installation or range snapshot commencement (Sheffi et al., 2022).

D. HTAP, Hybrid Workloads, Early Conflict Detection

MVCC faces challenges for hybrid OLTP/OLAP workloads (HTAP)—long scans, interleaved updates—where version chains become long, visibility checks expensive, and index maintenance heavy. MV-PBT stores version/timestamp info in partitioned B+ trees, enabling index-only visibility checks (analyzing $visible(v, \tau_s)$ predicates) and flash-friendly IO (Riegger et al., 2019). Early conflict detection and execution avoidance in blockchains (Fabric OEMVCC, EMVCC) pushes MVCC checks upstream to sequencers/orderers or peer caches, aborting doomed transactions before expensive simulation/execution (Stoltidis et al., 2024Trabelsi et al., 2023).

4. MVCC Optimization: Scheduling Space, Omission, Starvation-Freedom

Efficiency in ingestion-heavy scenarios is achieved by omitting unnecessary versions. SSE (and epoch-based ESSE) constructs erasing version orders $\preceq_e$ for blind updates and, after verifying serializability (acyclic MVSG) and linearizability, omits writes that will never be read. This can be implemented on MVTO, Silo, and similar protocols, yielding orders-of-magnitude scaling gains in analytic workloads (Nakazono et al., 2023). For STM, SF-MVOSTM uses per-transaction timestamps, dominance ranges, and multi-versioning to guarantee starvation-freedom (eventual commit) and local opacity, under heavy thread contention (Juyal et al., 2019).

5. MVCC in Hybrid Concurrency, OLTP/OLAP, RDMA, Blockchains

Hybrid protocols such as Shirakami combine MVCC for long transactions with Silo-style OCC for short transactions, using table-level write-preservation, per-tuple epoch metadata, epoch-based synchronization, and order-forwarding to enforce full serializability and efficient mixing of workloads (Kambayashi et al., 2023). For HTAP, safe snapshot and RSS models construct transaction cuts guaranteeing abort- and wait-free OLAP execution with serializability, using dependency graphs and periodic closure computations (Shioi et al., 2022). MVCC over RDMA (RCC) utilizes circular buffers of version metadata, local per-tuple locks, hybrid use of two-sided RPC and one-sided verbs (READ, CAS), doorbell batching, outstanding request pipelining, and hybrid execution stages for optimal network and PCIe utilization (Wang et al., 2020).

6. Complexity, Formal Verification, and Theoretical Comparisons

While conflict-serializability is polynomial-time decidable (via acyclicity tests on dependency graphs), view-serializability (and thus robustness under weaker criteria) is NP-complete (Vandevoort et al., 2024). Multiversion conflict graphs generalize classical single-version conflicts to accommodate multiple valid histories per object, and admit polynomial-time cycle checks for mvc-opacity (Kumar et al., 2015). MVCC’s formal correctness models—dependency graphs, acyclicity criteria, watermark exclusion, explicit validation and repair graphs—ensure rigorously provable guarantees, and can be extended to local opacity, virtual world consistency, and other transactional correctness criteria.

7. Impact, Best Practices, and Open Problems

MVCC has become foundational in transactional DBMS, STM, distributed ledgers, and high-performance key-value systems, due to its ability to eliminate read-write blocking, minimize abort rates, support analytical queries, and maximize concurrency. Key best practices include minimal reader bookkeeping (Bohm), latch-free stamp tracking (SSN, ESSN), index-only visibility filtering (MV-PBT), write omission in ingestion (SSE/ESSE), and per-epoch versioning (Shirakami). Open problems remain in adaptive partitioning, further minimizing false aborts, garbage collection strategies for long-tail versions, and automated controller design for regime switching between early abort and execution avoidance (Riegger et al., 2019Stoltidis et al., 2024).

MVCC continues to drive advances in concurrent transaction processing, formal verification, scalability engineering, and cross-domain protocol design across memory, storage, and networked environments.