Snapshot Isolation in TuringDB
TuringDB is designed to support ACID transactions with native snapshot isolation (SI) as a default, zero-cost feature. This section explains:- What snapshot isolation is
- Why it matters in graph databases
- How TuringDB achieves it differently from Neo4J or MemGraph
- And why it comes with no performance tradeoff in our architecture
What Is Snapshot Isolation?
Snapshot isolation (SI) is a database property that guarantees:A transaction sees a consistent snapshot of the database as it was at the start of the transaction.
Key Guarantees
- You only see committed data
- You never see uncommitted or intermediate states
- You never see the effects of future or concurrent transactions
- Your transaction operates on a stable, unchanging view of the graph
TuringDB is Fully ACID-Compliant
TuringDB supports the full ACID model:
Based on the definition of Jim Gray & Andreas Reuter (Gray & Reuter, 1993)
How persistence works. TuringDB is an in-memory engine with on-disk persistence. By default,
CHANGE SUBMIT synchronously writes the new commit and its constituent dataparts to the on-disk graph in the TuringDB directory (-turing-dir, default ~/.turing). DataParts are immutable, so previously-persisted ones are written once and shared — a submit appends only what’s new, it does not rewrite the whole graph. Once a change is submitted, its data and history survive a restart. Work inside a change — intermediate COMMITs and any un-submitted state — lives only in RAM until you submit.Running the server with -in-memory turns disk persistence off entirely — nothing is written.Industry Comparisons: Neo4J and MemGraph
Most graph databases fall short of true snapshot isolation.Neo4J
- Default isolation level: Read Committed
- This means you might observe changes from concurrent transactions
- Neo4J allows non-repeatable reads unless you manually manage locks
- Full SI is not enforced unless using explicit log-based transaction locking
Risk: Unpredictable graph states in analytics or during parallel workflows.
MemGraph
- Claims to be ACID-compliant
- Offers multiple isolation levels, but not full snapshot isolation by default
- Isolation behavior depends on how queries and write batches are structured
Risk: Reads and writes may conflict without explicit coordination.
TuringDB’s Approach to Snapshot Isolation
TuringDB provides Snapshot Isolation by default, and critically:It comes at zero performance cost.Here’s how:
Versioned Graphs by Design
Every graph in TuringDB is stored as a sequence of immutable commits, much like Git. Each commit is composed of DataParts, read-optimized storage chunks for nodes and edges.- Each transaction runs against a specific commit snapshot
- That snapshot is immutable and isolated
- Reads do not block writes, and vice versa
- You can always “time travel” to past states by checking out any previous commit
TuringDB doesn’t need to acquire write locks or maintain transaction logs for reads. SI is built-in, not bolted on.See also: DataParts and Versioning
Why It Matters
Further Reading
- Gray, J., & Reuter, A. (1993). Distributed Transaction Processing
- Haerder, T., & Reuter, A. (1983). Principles of transaction-oriented DB recovery
- Fekete et al. (2005). Making Snapshot Isolation Serializable
- A Critique of ANSI SQL Isolation Levels (Berenson et al., 1995)
Summary
TuringDB offers built-in Snapshot Isolation that is: ✅ Default ✅ Immutable ✅ Fast ✅ Lock-free ✅ Compatible with analytics and AI use cases ✅ Based on a Git-like architecture built for parallelism and consistencyIt’s the first graph database to natively combine versioning, immutability, and snapshot isolation, without the tradeoffs.