Birth and death of a row in Turso's MVCC

Turso’s MVCC mode redesigns SQLite-compatible write handling to support concurrent writers while preserving durability and recovery, tracing a row’s lifecycle from SQL compilation into SQLite VDBE bytecode through insertion, commit, checkpointing, and deletion. New rows first enter an in-memory, lock-free SkipMap as version chains marked with transaction IDs, becoming visible to other transactions only after conflict validation, dependency checks, logical-log writing, and fsync establish a durable commit timestamp. The logical log enables crash recovery by replaying committed operations into memory, while checkpoints periodically transfer eligible in-memory data through SQLite’s WAL into the B-tree database file, using either blocking truncate checkpoints or an experimental less-blocking passive mode. Reads merge data from the in-memory MVCC store and persistent B-tree using snapshot isolation, giving newer in-memory versions precedence, while deletes mark a row version’s end timestamp and detect competing writes as conflicts. The implementation aims to overcome SQLite WAL mode’s single-writer limitation, particularly for Turso’s small databases serving parallel agent workloads, while retaining SQLite file compatibility through the `PRAGMA journal_mode = mvcc` option.

No tracked trend matches for this post yet.

Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.