🔒 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:| 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 | Once committed, data survives crashes and restarts |
🆚 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 commitTuringDB 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 consistencyIt’s the first graph database to natively combine versioning, immutability, and snapshot isolation, without the tradeoffs.