Mvcc

tursodatabase/turso/.claude/skills/mvcc

by tursodatabaseff97ec42cdefNo license24K starsListed Oct 9, 2026Updated Oct 8, 2026Repository updated today

Overview of Experimental MVCC feature - snapshot isolation, versioning, limitations

Instructions onlySoftware Development
AI-generated overview

Explains an experimental MVCC storage mode: enabling it, architecture, checkpointing, limitations and testing.

What it does
This skill is a reference guide to an experimental multi-version concurrency control (MVCC) feature in a database engine. It covers how to enable MVCC via a journal-mode pragma, how row versioning and snapshot isolation differ from WAL, the internal architecture and key source files, checkpointing behavior and its pragma, current limitations, and how to run MVCC-specific tests. It produces explanatory guidance rather than code or files.
When to use it
Use it when you need orientation on this experimental MVCC mode, such as enabling it, understanding its versioning and checkpoint model, or finding the relevant source files and tests. It is also useful for judging whether a bug is MVCC-specific before debugging.
Requirements
No scripts or tools are required; it is instructions-only reference material. The testing section references a Rust toolchain with cargo and make for the host project, but the skill itself needs nothing beyond the agent.

MVCC Guide (Experimental)

Multi-Version Concurrency Control. Work in progress, not production-ready.

CRITICAL: Ignore MVCC when debugging unless the bug is MVCC-specific.

Enabling MVCC

sql
PRAGMA journal_mode = 'mvcc';

Runtime configuration, not a compile-time feature flag. Per-database setting.

How It Works

Standard WAL: single version per page, readers see snapshot at read mark time.

MVCC: multiple row versions, snapshot isolation. Each transaction sees consistent snapshot at begin time.

Key Differences from WAL

AspectWALMVCC
Write granularityEvery commit writes full pagesAffected rows only
Readers/WritersDon't block each otherDon't block each other
Persistence.db-wal.db-log (logical log)
IsolationSnapshot (page-level)Snapshot (row-level)

Versioning

Each row version tracks:

  • begin - timestamp when visible
  • end - timestamp when deleted/replaced
  • btree_resident - existed before MVCC enabled

Architecture

Database  └─ mv_store: MvStore      ├─ rows: SkipMap<RowID, Vec<RowVersion>>      ├─ txs: SkipMap<TxID, Transaction>      ├─ Storage (.db-log file)      └─ CheckpointStateMachine

Per-connection: mv_tx tracks current MVCC transaction.

Shared: MvStore with lock-free crossbeam_skiplist structures.

Key Files

  • core/mvcc/mod.rs - Module overview
  • core/mvcc/database/mod.rs - Main implementation (~3000 lines)
  • core/mvcc/cursor.rs - Merged MVCC + B-tree cursor
  • core/mvcc/persistent_storage/logical_log.rs - Disk format
  • core/mvcc/database/checkpoint_state_machine.rs - Checkpoint logic

Checkpointing

Flushes row versions to B-tree periodically.

sql
PRAGMA mvcc_checkpoint_threshold = <pages>;

Process: acquire lock → begin pager txn → write rows → commit → truncate log → fsync → release.

Current Limitations

Not implemented:

  • Garbage collection (old versions accumulate)
  • Recovery from logical log on restart

Known issues:

  • Checkpoint blocks other transactions, even reads!
  • No spilling to disk; memory use concerns

Testing

bash
# Run MVCC-specific testscargo test mvcc
# TCL tests with MVCCmake test-mvcc

Use #[turso_macros::test(mvcc)] attribute for MVCC-enabled tests.

rust
#[turso_macros::test(mvcc)]fn test_something() {    // runs with MVCC enabled}

References

  • core/mvcc/mod.rs documents data anomalies (dirty reads, lost updates, etc.)
  • Snapshot isolation vs serializability: MVCC provides the former, not the latter

Source and attribution

Source:tursodatabase/tursoin.claude/skills/mvccat commitff97ec4

License: No license

Content belongs to its original authors. SourceWeft indexes it from a public repository.

Report or request removal