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
Definition adapted from the classic ACID transaction model
(Gray & Reuter, 1993; Haerder & Reuter, 1983)
TuringDB is Fully ACID-Compliant
TuringDB supports the full ACID model:
| Principle | Meaning |
|---|---|
| Atomicity | All-or-nothing: if a transaction fails, nothing is applied |
| Consistency | Every transaction transforms the graph from one valid state to another |
| Isolation | Each transaction operates as if it’s the only one |
| Durability | Submitting a change writes its new commit to disk (see note) |
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
📎 MemGraph blog: ACID & Isolation
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
| Feature | Without SI | With Snapshot Isolation (TuringDB) |
|---|---|---|
| Concurrent analytics | Risk of inconsistency | ✅ Always safe and repeatable |
| LLM or AI agent reads | Can see in-progress updates | ✅ Only sees committed graph states |
| Live dashboards | Glitches from concurrent writes | ✅ Never interrupted or corrupted |
| Graph training workflows | Risk of nondeterminism | ✅ Guaranteed reproducibility |
| Rollbacks or audits | Hard to trace | ✅ Time-travel enabled by commit history |
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 consistency
It’s the first graph database to natively combine versioning, immutability, and snapshot isolation, without the tradeoffs.