FAQs

TuringDB is a column-oriented graph database written in C++ with native versioning, built for speed, versioning and memory efficiency. It stores data as a labelled property graph, nodes and edges both carrying unlimited properties, and is queried with Cypher. There is a full technical specification if you want the detail.

Properties are stored in contiguous columns rather than as self-contained node records, and query operators process whole batches at once using SIMD instructions. Data lives in immutable DataParts, so a read never contends with a write, and keeping the old parts around is nearly free. That last detail is why versioning is an engine primitive here rather than something bolted on afterwards. There is more on the architecture.

Columnar storage and vectorized execution, the architecture that made ClickHouse and DuckDB fast for analytics, applied to graph traversal instead. On the Reactome benchmark a 6-hop traversal returns in 493 ms where Neo4j takes 17,983 ms and Memgraph 17,256 ms. The advantage grows with depth, because latency climbs slowly rather than by orders of magnitude. The full methodology and conditions are published.

Every write is an immutable commit. You can branch the graph, merge branches, diff two states, roll back, and query any historical version at full speed. A past version is a real materialized state rather than a log replayed on demand, so querying history costs the same as querying the present. It is explained in depth here.

No. In-memory describes the working representation used for query execution. Persistence is real and durable.

Self-hosted as a server, on-premise, air-gapped, or in-process and embedded and driven directly from Python. The embedded mode suits notebooks, single-analyst workflows and CI pipelines, and the same database can also be deployed as a multi-client server, so a workload does not have to be rewritten when it moves from a laptop to production.

Yes, a subset of openCypher. Most Neo4j queries port with little or no change. Checking your heaviest queries against the supported clause list is the first step of any migration assessment.

No. The columnar layout acts as a natural index, so there are no index build steps to plan and no index maintenance to tune.

Hundreds of millions of nodes and billions of edges on a single machine. The compact columnar representation is what makes that possible on ordinary server hardware rather than a specially provisioned large-memory box.

Yes. Concurrency is handled by immutability rather than locking, with full snapshot isolation. Ingest pipelines write while analytical queries read, and neither blocks the other.

Yes, vector search is built into the engine, so semantic entry points and graph traversal live in one system rather than two.

The community edition is open source on GitHub. It is a working product rather than a feature-stripped demo. Enterprise and Custom tiers add engineering support and bespoke work.

The community edition is free and open source. Enterprise and Custom pricing is published here.

Turing Biosystems Ltd, based in London and Lyon, originally a University of Manchester spinout building graph-based software for clinical research and development. The graph engine underneath that work is what became TuringDB. There is more about the team.