TuringDB high performance in-memory column-oriented graph database engine
See the code
Website • Documentation • Quickstart • Discord • Examples
TuringDB is a high-performance, in-memory, column-oriented graph database engine, built in C++ for analytical, AI-driven, and read-intensive workloads.
With version-controlled storage, zero-locking execution, and integrated vector search for GraphRAG and embeddings, it gives you low-latency queries, snapshot isolation, and seamless integration with modern AI pipelines.
It is designed around three properties: fast multi-hop traversals, native Git-style versioning, and minimal memory footprint.
Get from zero to your first query in under a minute.
pip install turingdb
# uv (create a project first, then turingdb is on your $PATH)
uv add turingdb
# curl install script
curl https://install.turingdb.ai | bash
# Docker (other methods are preferred, Docker has some performance overhead)
docker run -it turingdbai/turingdb:nightly turingdb
# nix, available on the nixpkgs unstable channel (x86 Linux and AArch64 macOS)
nix run nixpkgs/nixos-unstable#turingdb
TuringDB runs in-process, right inside your Python program, with no separate server to start. Ideal if you want to embed it directly in your application:
from turingdb import TuringDB
# Embedded mode, no server to start
client = TuringDB(type="embedded", data_dir="~/.turing")
client.create_graph("social")
client.set_graph("social")
# Writes go through a versioned change: create, commit, submit
change = client.new_change()
client.checkout(change=change)
client.query("""
CREATE (a:Person {name: 'Alice', age: 30})
CREATE (b:Person {name: 'Bob', age: 25})
CREATE (a)-[:KNOWS {since: 2020}]->(b)
""")
client.query("COMMIT")
client.query("CHANGE SUBMIT")
client.checkout()
# Reads come back as a pandas DataFrame
df = client.query("MATCH (a:Person)-[:KNOWS]->(b) RETURN a.name, b.name")
print(df)
That is it. You have created a graph, written a versioned change, and queried it.
Prefer a long-running server (REST API on http://localhost:6666)?
turingdb # foreground / interactive
turingdb -demon # background (daemon); stop with `turingdb stop`
turingdb -ui # launch with the graph visualizer
Then point the client at it:
client = TuringDB(host="http://localhost:6666")
See the full Quickstart and Python SDK guide for more.
TuringDB ships with a WebGL-accelerated graph visualizer for exploring large graphs in the browser. Launch it by starting TuringDB with the -ui flag:
turingdb -ui
Once started, open the visualizer at http://127.0.0.1:8080 (or the port set via -ui-port).
Options
| Flag | Description | Default |
|---|---|---|
-ui | Launch the built-in visualizer | off |
-ui-port <port> | Visualizer port | 8080 |
For example, to run TuringDB as a background daemon with the UI on a custom port:
turingdb -demon -ui -ui-port 9090
Example: Europe power grid generation and distribution network modeled as a graph in TuringDB
Deep multi-hop traversals stay in the millisecond range even on very large graphs, so a fraud check or cohort lookup returns now, not in minutes.
Every change is an immutable commit you can branch, merge, roll back, and time-travel through at full speed, making auditability native for finance, compliance, insurance, and supply chain.
A compact in-memory representation runs multi-million node graphs on modest hardware, so you can deploy in the cloud, at the edge, or embedded in local hardware.
Read the documentation for the full architecture and design considerations.
TuringDB is commonly 35x to 480x faster than Neo4j and Memgraph on label scans and multi-hop traversals.
Benchmarked on the public Reactome knowledge graph: 2,978,202 nodes, 11,537,843 relationships, 108 node labels, 88 relationship types. Specs: Intel Xeon Gold 5412U (48 cores), 251.4 GB RAM, SSD, Ubuntu 24.04.3 LTS.
All results are cold runs, with no indexing or tuning on either side. TuringDB is queried over HTTP; Neo4j and Memgraph over Bolt.
| Query | TuringDB | Neo4j | Memgraph | Speedup vs Neo4j | Speedup vs Memgraph |
|---|---|---|---|---|---|
MATCH (n:Drug) RETURN n | 2 ms | 977 ms | 371 ms | 488x | 186x |
MATCH (n:ProteinDrug) RETURN n | 1 ms | 221 ms | 340 ms | 221x | 340x |
MATCH (n:Drug:ProteinDrug) RETURN n | 1 ms | 270 ms | 359 ms | 270x | 359x |
MATCH (n:Taxon)-->(m:Species) RETURN n,m | 1 ms | 259 ms | 301 ms | 259x | 301x |
MATCH (n)-->(m:Interaction)-->(o) RETURN n,m,o | 707 ms | 33,117 ms | 32,609 ms | 47x | 46x |
MATCH (n:Pathway)-[:hasEvent]->(m:ReactionLikeEvent) RETURN n,m | 94 ms | 8,442 ms | 8,696 ms | 90x | 93x |
MATCH (r:ReactionLikeEvent)-[:output]->(s:PhysicalEntity) RETURN r,s | 184 ms | 13,383 ms | 13,591 ms | 73x | 74x |
MATCH (n {displayName: "Autophagy"})-->(m)-->(p)-->(q)-->(r)-->(s)-->(t) RETURN t | 493 ms | 17,983 ms | 17,256 ms | 36x | 35x |
Run these yourself with turing-bench, or see the detailed benchmarks for full methodology.
Agentic systems reason over graphs, and they need answers in the loop, not after a stall. TuringDB fits the way agents actually work:
How TuringDB is used across critical industries:
TuringDB speaks a Cypher dialect, so here it is in the interactive shell:
// Create nodes
CREATE (alice:Person {name: 'Alice', age: 30})
CREATE (bob:Person {name: 'Bob', age: 25})
CREATE (computers:Interest {name: 'Computers'})
// Create relationships
MATCH (a:Person {name: 'Alice'}), (b:Person {name: 'Bob'})
CREATE (a)-[:KNOWS {since: 2020}]->(b)
MATCH (a:Person {name: 'Alice'}), (i:Interest {name: 'Computers'})
CREATE (a)-[:INTERESTED_IN]->(i)
// Query the graph
MATCH (a:Person)-->(b)
WHERE a.age > 25
RETURN a.name, b.name
Versioning lets you ask what the graph looked like at any past point, which is the basis for audit and agent explainability:
# Query a historical version of the graph at full speed
client.checkout(change=previous_change)
df = client.query("MATCH (a:Account)-[:SENT]->(b:Account) RETURN a.id, b.id")
client.checkout() # back to the latest state
Load existing graphs into TuringDB from common formats (import guide):
LOAD JSONLLOAD CSV to drive CREATE or RETURNLOAD GMLReal-world, end-to-end notebooks across domains, from fraud detection to biological graph exploration, showing off TuringDB's speed and versioning.
Finance and Fraud
Transport and Supply Chain
Healthcare and Life Sciences
Browse them all at turing-db/turingdb-examples
Visualizing a massive mesh graph with OpenGL-accelerated graph visualization
TuringDB runs natively on x86-64 and ARM 64-bit platforms. SSD or NVMe storage is recommended.
Requirements
Linux:
macOS:
Build
# 1. Clone with submodules
git clone --recursive https://github.com/turing-db/turingdb.git
cd turingdb
./pull.sh
# 2. Install dependencies (run once)
# Builds/installs: Curl, OpenSSL, GNU Bison and Flex, Boost,
# OpenBLAS, AWS SDK for C++, and the Faiss vector-search library
./dependencies.sh
# 3. Build
mkdir -p build && cd build
cmake ..
make -j8
make install
# 4. Add turingdb binaries to your current shell's $PATH
source setup.sh
We welcome contributions. Check the open issues to get started, and reach out at team@turingdb.ai if you would like to get involved.
TuringDB Community Edition is licensed under the Business Source License (BSL). See LICENSE for details.
Built for the graph database community. If TuringDB is useful to you, please star the repo.
C++
92.7%
CMake
2.1%
Python
1.7%
Shell
1.2%
TypeScript
1.1%
TuringDB high performance in-memory column-oriented graph database engine
See the code
Website • Documentation • Quickstart • Discord • Examples
TuringDB is a high-performance, in-memory, column-oriented graph database engine, built in C++ for analytical, AI-driven, and read-intensive workloads.
With version-controlled storage, zero-locking execution, and integrated vector search for GraphRAG and embeddings, it gives you low-latency queries, snapshot isolation, and seamless integration with modern AI pipelines.
It is designed around three properties: fast multi-hop traversals, native Git-style versioning, and minimal memory footprint.
Get from zero to your first query in under a minute.
pip install turingdb
# uv (create a project first, then turingdb is on your $PATH)
uv add turingdb
# curl install script
curl https://install.turingdb.ai | bash
# Docker (other methods are preferred, Docker has some performance overhead)
docker run -it turingdbai/turingdb:nightly turingdb
# nix, available on the nixpkgs unstable channel (x86 Linux and AArch64 macOS)
nix run nixpkgs/nixos-unstable#turingdb
TuringDB runs in-process, right inside your Python program, with no separate server to start. Ideal if you want to embed it directly in your application:
from turingdb import TuringDB
# Embedded mode, no server to start
client = TuringDB(type="embedded", data_dir="~/.turing")
client.create_graph("social")
client.set_graph("social")
# Writes go through a versioned change: create, commit, submit
change = client.new_change()
client.checkout(change=change)
client.query("""
CREATE (a:Person {name: 'Alice', age: 30})
CREATE (b:Person {name: 'Bob', age: 25})
CREATE (a)-[:KNOWS {since: 2020}]->(b)
""")
client.query("COMMIT")
client.query("CHANGE SUBMIT")
client.checkout()
# Reads come back as a pandas DataFrame
df = client.query("MATCH (a:Person)-[:KNOWS]->(b) RETURN a.name, b.name")
print(df)
That is it. You have created a graph, written a versioned change, and queried it.
Prefer a long-running server (REST API on http://localhost:6666)?
turingdb # foreground / interactive
turingdb -demon # background (daemon); stop with `turingdb stop`
turingdb -ui # launch with the graph visualizer
Then point the client at it:
client = TuringDB(host="http://localhost:6666")
See the full Quickstart and Python SDK guide for more.
TuringDB ships with a WebGL-accelerated graph visualizer for exploring large graphs in the browser. Launch it by starting TuringDB with the -ui flag:
turingdb -ui
Once started, open the visualizer at http://127.0.0.1:8080 (or the port set via -ui-port).
Options
| Flag | Description | Default |
|---|---|---|
-ui | Launch the built-in visualizer | off |
-ui-port <port> | Visualizer port | 8080 |
For example, to run TuringDB as a background daemon with the UI on a custom port:
turingdb -demon -ui -ui-port 9090
Example: Europe power grid generation and distribution network modeled as a graph in TuringDB
Deep multi-hop traversals stay in the millisecond range even on very large graphs, so a fraud check or cohort lookup returns now, not in minutes.
Every change is an immutable commit you can branch, merge, roll back, and time-travel through at full speed, making auditability native for finance, compliance, insurance, and supply chain.
A compact in-memory representation runs multi-million node graphs on modest hardware, so you can deploy in the cloud, at the edge, or embedded in local hardware.
Read the documentation for the full architecture and design considerations.
TuringDB is commonly 35x to 480x faster than Neo4j and Memgraph on label scans and multi-hop traversals.
Benchmarked on the public Reactome knowledge graph: 2,978,202 nodes, 11,537,843 relationships, 108 node labels, 88 relationship types. Specs: Intel Xeon Gold 5412U (48 cores), 251.4 GB RAM, SSD, Ubuntu 24.04.3 LTS.
All results are cold runs, with no indexing or tuning on either side. TuringDB is queried over HTTP; Neo4j and Memgraph over Bolt.
| Query | TuringDB | Neo4j | Memgraph | Speedup vs Neo4j | Speedup vs Memgraph |
|---|---|---|---|---|---|
MATCH (n:Drug) RETURN n | 2 ms | 977 ms | 371 ms | 488x | 186x |
MATCH (n:ProteinDrug) RETURN n | 1 ms | 221 ms | 340 ms | 221x | 340x |
MATCH (n:Drug:ProteinDrug) RETURN n | 1 ms | 270 ms | 359 ms | 270x | 359x |
MATCH (n:Taxon)-->(m:Species) RETURN n,m | 1 ms | 259 ms | 301 ms | 259x | 301x |
MATCH (n)-->(m:Interaction)-->(o) RETURN n,m,o | 707 ms | 33,117 ms | 32,609 ms | 47x | 46x |
MATCH (n:Pathway)-[:hasEvent]->(m:ReactionLikeEvent) RETURN n,m | 94 ms | 8,442 ms | 8,696 ms | 90x | 93x |
MATCH (r:ReactionLikeEvent)-[:output]->(s:PhysicalEntity) RETURN r,s | 184 ms | 13,383 ms | 13,591 ms | 73x | 74x |
MATCH (n {displayName: "Autophagy"})-->(m)-->(p)-->(q)-->(r)-->(s)-->(t) RETURN t | 493 ms | 17,983 ms | 17,256 ms | 36x | 35x |
Run these yourself with turing-bench, or see the detailed benchmarks for full methodology.
Agentic systems reason over graphs, and they need answers in the loop, not after a stall. TuringDB fits the way agents actually work:
How TuringDB is used across critical industries:
TuringDB speaks a Cypher dialect, so here it is in the interactive shell:
// Create nodes
CREATE (alice:Person {name: 'Alice', age: 30})
CREATE (bob:Person {name: 'Bob', age: 25})
CREATE (computers:Interest {name: 'Computers'})
// Create relationships
MATCH (a:Person {name: 'Alice'}), (b:Person {name: 'Bob'})
CREATE (a)-[:KNOWS {since: 2020}]->(b)
MATCH (a:Person {name: 'Alice'}), (i:Interest {name: 'Computers'})
CREATE (a)-[:INTERESTED_IN]->(i)
// Query the graph
MATCH (a:Person)-->(b)
WHERE a.age > 25
RETURN a.name, b.name
Versioning lets you ask what the graph looked like at any past point, which is the basis for audit and agent explainability:
# Query a historical version of the graph at full speed
client.checkout(change=previous_change)
df = client.query("MATCH (a:Account)-[:SENT]->(b:Account) RETURN a.id, b.id")
client.checkout() # back to the latest state
Load existing graphs into TuringDB from common formats (import guide):
LOAD JSONLLOAD CSV to drive CREATE or RETURNLOAD GMLReal-world, end-to-end notebooks across domains, from fraud detection to biological graph exploration, showing off TuringDB's speed and versioning.
Finance and Fraud
Transport and Supply Chain
Healthcare and Life Sciences
Browse them all at turing-db/turingdb-examples
Visualizing a massive mesh graph with OpenGL-accelerated graph visualization
TuringDB runs natively on x86-64 and ARM 64-bit platforms. SSD or NVMe storage is recommended.
Requirements
Linux:
macOS:
Build
# 1. Clone with submodules
git clone --recursive https://github.com/turing-db/turingdb.git
cd turingdb
./pull.sh
# 2. Install dependencies (run once)
# Builds/installs: Curl, OpenSSL, GNU Bison and Flex, Boost,
# OpenBLAS, AWS SDK for C++, and the Faiss vector-search library
./dependencies.sh
# 3. Build
mkdir -p build && cd build
cmake ..
make -j8
make install
# 4. Add turingdb binaries to your current shell's $PATH
source setup.sh
We welcome contributions. Check the open issues to get started, and reach out at team@turingdb.ai if you would like to get involved.
TuringDB Community Edition is licensed under the Business Source License (BSL). See LICENSE for details.
Built for the graph database community. If TuringDB is useful to you, please star the repo.
C++
92.7%
CMake
2.1%
Python
1.7%
Shell
1.2%
TypeScript
1.1%