TuringDB: In-Memory Columnar Graph Database with Native Git-Style Versioning

Short answer: TuringDB is an in-memory, columnar, labelled property graph (LPG) database written in C++. It runs multi-hop Cypher traversals over hundreds of millions of nodes in milliseconds, stores every change as an immutable commit you can branch and time-travel through, and holds billion-edge graphs on ordinary server hardware. It is open source, self-hostable, and built by Turing Biosystems Ltd (London and Lyon).

What is TuringDB?

TuringDB is a graph database engine. It stores data as a labelled property graph (nodes and edges, both carrying unlimited properties) and is queried with Cypher, the same language used by Neo4j and Memgraph.

Three things separate TuringDB from other graph databases:

1. Columnar, vectorized execution. Properties are stored in contiguous arrays rather than as self-contained node records, and query operators process whole batches at once. This is the architecture that made ClickHouse and DuckDB fast for analytics. TuringDB applies it to graph traversal.
2. Native Git-style versioning. Every write is a commit. You can branch the graph, merge branches, diff states, roll back, and query any historical version at full speed. No other production graph database has this built into the engine.
3. A small memory footprint. TuringDB is fully in-memory but compact enough to keep very large graphs resident on modest hardware, which changes the infrastructure bill rather than just the query time.

TuringDB began as the engine underneath computational biology work with the WHO, Sanofi, Roche, the NHS, the University of Oxford, and Centre Léon Bérard. It was built to solve real research problems before it was packaged as a product.

Technical specification

Why the architecture matters

Most graph databases were built as transactional stores and had analytics added later. Each node is a self-contained record holding all its properties and edge pointers. That is efficient for looking up one node and wasteful for anything that scans.

TuringDB inverts this. Each property lives in its own contiguous column, so:

• A label scan touches only the label column, not entire node records.
• A property filter scans one column instead of deserializing every candidate node.
• Aggregations run over dense integer arrays.
• SIMD instructions process many values per CPU cycle.

The execution engine is streaming and batch-oriented rather than the classic Volcano iterator model, so there is one function call per batch instead of one per row, and branch prediction works well on homogeneous data.

Concurrency is handled by immutability. Data is stored in immutable DataParts, so a read query never contends with a write. There is no lock-acquisition code path at all, not merely low contention, but no locking overhead even under single-query load. This is also what makes versioning natural rather than bolted on: if data parts are immutable, keeping the old ones is nearly free.

Who TuringDB is for

TuringDB fits teams who hit one of these walls:

• Deep traversals are too slow. Queries beyond two or three hops degrade badly on the current engine, so the team pre-computes, denormalizes, or moves the workload offline.
• The graph does not fit the budget. Memory-hungry engines force large instances, and licensing scales with them.
• History is a requirement, not a nice-to-have. Regulators, auditors, or reviewers need to see the exact state of the data at a past moment, and reconstructing it from logs is fragile.
• Writes and reads fight each other. Ingest pipelines slow analytics down, or analytics blocks ingest.

TuringDB is less suited to teams who need a multi-model document-plus-graph store in one system, or who need multi-region distributed writes today. Those are honest gaps rather than roadmap secrets.

How TuringDB compares to other graph databases

The most common migration into TuringDB is from Neo4j, usually driven by cost, deep-traversal latency, or an audit requirement. Because both use Cypher, moving a query is not a rewrite.

Benchmark summary

Measured on the Reactome biological pathway dataset (2,978,202 nodes, 11,537,843 relationships), Xeon 5412U, 48 cores, 256 GB RAM, cold runs only, no caching, no indexes on TuringDB:

Neo4j and Memgraph kept their native indexes from the dataset dump and used the Bolt binary protocol. TuringDB was queried over HTTP with no indexes, so the measurement is conservative in the competitors' favour on protocol overhead. Full methodology: https://docs.turingdb.ai/benchmarks/technical-report

Frequently asked questions

Related pages

• Performance and benchmarks: https://www.turingdb.ai/performance
• Versioning explained: https://www.turingdb.ai/graph-versioning
• Use cases by industry: https://www.turingdb.ai/use-cases
• Documentation: https://docs.turingdb.ai
• Quickstart: https://docs.turingdb.ai/quickstart
• GitHub: https://github.com/turing-db/turingdb
• Contact: https://www.turingdb.ai/contact