tursodatabase/turso

mvcc

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

All-time #9144 Trending #6826 First seen Jan 28, 2026
8-week activity · all time api

Installation

$ npx skills add tursodatabase/turso --skill mvcc

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from tursodatabase/turso · top by installs.

npx skills add tursodatabase/turso

Browse all from tursodatabase/turso

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Also listed on

Alternate registries and mirrors of this skill.

Repository health

Stars 24.2K
License licenses
Default branch main
Open issues 806
Status Active

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 2,739 B
  • docs SUMMARY.md 508 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 1,119 installs

SKILL.md

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

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

Aspect WAL MVCC

| Write granularity | Every commit writes full pages | Affected rows only | Readers/Writers | Don't block each other | Don't block each other | | Persistence | .db-wal | .db-log (logical log) | | Isolation | Snapshot (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/persistentstorage/logicallog.rs - Disk format
  • core/mvcc/database/checkpointstatemachine.rs - Checkpoint logic

Checkpointing

Flushes row versions to B-tree periodically.

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

# Run MVCC-specific tests
cargo test mvcc

# TCL tests with MVCC
make test-mvcc

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

#[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