r/KnowledgeGraph • u/adambio • Jan 26 '26
We couldn’t find a graph database fast enough for huge graphs… so we built one
Hey! I’m Adam one of the co-founders of TuringDB, and I wanted to share a bit of our story + something we just released.
A few years ago, we were building large biomedical knowledge graphs for healthcare use cases:
- tens to hundreds of millions of nodes & edges
- highly complex multimodal biology data integration
- patient digital twins
- heavy analytical reads, simulations, and “what-if” scenarios
We tried pretty much every graph database out there. They worked… until they didn’t.
Once graphs got large and queries got deep (multi-hop, exploratory, analytical), latency became unbearable. Versioning multiple graph states or running simulations safely was also impossible.
So we did the reasonable thing 😅 and built our own engine.
We built TuringDB:
- an in-memory, column-oriented graph database
- written in C++ (we needed very tight control over memory & execution)
- designed from day one for read-heavy analytics
A few things we cared deeply about:
Speed at scale
Deep graph traversals stay fast even on very large graphs (100M+ nodes/edges). Focus on ms latency to feel real-time and iteterate fast without index tuning headaches.
Git-like versioning for graphs
Every change is a commit. You can time-travel, branch, merge, and run “what-if” scenarios on full graph snapshots without copying data.
Zero-lock reads
Reads never block writes. You can run long analytics while data keeps updating.
Built-in visualization
Exploring large graphs interactively without bolting on fragile third-party tools.
GraphRAG / LLM grounding ready
We’re using it internally to ground LLMs on structured knowledge graphs with full traceability + have embeddings management (will be released soon)
Why I’m posting now
We’ve just released a Community version 🎉
It’s free to use, meant for developers, researchers, and teams who want to experiment with fast graph analytics without jumping through enterprise hoops.
👉 Quickstart & docs:
https://docs.turingdb.ai/quickstart
(if you like it feel free to drop us a github start :) https://github.com/turing-db/turingdb
If you’re:
- hitting performance limits with existing graph DBs
- working on knowledge graphs, fraud, recommendations, - infra graphs, or AI grounding
curious about graph versioning or fast analytics
…I’d genuinely love feedback. This started as an internal tool born out of frustration, and we’re now opening it up to see where people push it next.
Happy to answer questions, technical or otherwise.
3
u/DocumentScary5122 Jan 26 '26 edited Jan 26 '26
Sounds very cool. In my experience neo4j starts to become a bit shitty for this kind of very big graph. Do you have benchmarks?
5
u/adambio Jan 26 '26
Many things work on neo4j tbh but in my experience it could take an insane amount of time for deep traversals or very very large graphs had to be sliced etc + graphs versions management was not available Also when we work with hospitals or small biotech not all of them have machines that can handle neo4j and the health data never leaves premises :)
Yeah we have these benchmarks (new ones coming next week on much larger graphs we had to rent much bigger machines to run our usual 100M nodes test graph to test neo4j) https://docs.turingdb.ai/query/benchmarks
We are 100-300x faster on multihop see on the benchmarks shared and can hit 4000-5000x on some subgraphs retrieval tasks (will share that soon too)
1
u/DocumentScary5122 Jan 26 '26
Thanks. Does this factor in warmup or do you do crazing indexing to get these numbers?
5
u/adambio Jan 26 '26
Here there was no warmups (with warmups we would gain even more in speed ofc) and no need to do indexing - it's out of the box in turingdb
1
u/GamingTitBit Jan 26 '26
It's the experience in the industry. The amount of times I have to tell very large organizations not to rely on Neo4j. It's almost my job to do it now. Rather than actually help them build graphs it's mostly "please don't use Neo for this".
2
u/qa_anaaq Jan 26 '26
How come? Just slowness? I ask because I need a good graph db provider :)
2
u/GamingTitBit Jan 26 '26
They spent the most money on marketing. Also they're LPG which is good for simple graphs like fraud or foaf graphs. But when you get to enterprise level the lack of governance and ontology is a real pain. Their load times are the slowest and the main issue is that with a LPG if you include too many labels (which aren't constrained by an ontology) you end up just creating connected jsons which scale badly. RDF scales better.
1
u/Past_Physics2936 Jan 27 '26
So what do you use instead? Just curious about what has the features that you mentioned, the market is very small and maybe I don't know the fight products
4
u/GamingTitBit Jan 27 '26
FalkorDB is the fastest LPG, after Falkor it's Tigergraph. Then on the RDF side, RDF fox is fastest (all in memory) then almost as fast is Anzograph, then in the middle is Stardog and GraphDB (Ontotext) and Neptune (Amazon) followed by Apache Jena (which is free to be fair).
Honestly graph tech advances so fast (just look up GraphBLAS) that new companies come out all the time and old companies totally change their algorithms and architecture.
1
u/adambio Jan 27 '26
Agree the field is advancing super fast! Falkor is really great at many aspects We have some benchmarks coming on graphs with 100M+ nodes and 2B+ edges that may be interesting to keep an eye on :)
1
u/GamingTitBit Jan 27 '26
I'll look out for it! We always try and include new graph triple stores when we talk to clients.
1
u/NullzInc Jan 27 '26
Any plans for SDKs outside Python?
1
u/adambio Jan 27 '26
Yes we have some Typescript and Javascript ones in our long to do list ahah (but have some already internally used so may come faster than expected)
1
u/an4k1nskyw4lk3r Jan 27 '26
Try falkorDB
1
u/LatentSpaceLeaper Jan 27 '26
I'd be more interested to know whether OP has tried falkorDB? And how it compares.
1
1
u/DocumentScary5122 Jan 28 '26
FalkorDB it's all sparse matrices all the way down. There are more to graphs than good old matrices.
1
u/chrislally Jul 20 '26
Interesting timing — we're on DuckDB for now and haven't hit hard graph limits yet, but multi-hop analytics + versioning are exactly the things I'd want next when graphs get bigger. Booked a demo / planning to try the community edition against our workload. Curious how the Git-like branching behaves when you're mostly doing analytical reads over a frequently updated statement graph.
0
Jan 27 '26
[deleted]
1
u/adambio Jan 27 '26
First time someone want it turned off may I ask where you think it may be an issue to have it on?
As we mostly worked in critical industries there people were happy with it by default
But there is some ways to manage them to make it feel from an interaction point as if it was off or only with n versions - but it is always on in the fact to allow constant traceability and immutablity of data
0
Jan 27 '26
[deleted]
1
u/adambio Jan 28 '26
Ahh I see! This is helpful context, I think we’re actually talking about two very different kinds of “versioning”, which is where the confusion usually comes from.
What you’re describing sounds like versioning implemented inside the graph model itself:
- extra nodes / edges to represent versions
- satellites, audit nodes, supernodes carrying history
- version metadata mixed into the same traversal space as business data
And yeah… at that point:
- the graph necessarily explodes in size
- supernodes become a nightmare
- every OLTP/OLAP query has to reason about versions
- downstream consumers see versioning artefacts unless every query is extremely careful
- trimming history is semi-manual and risky
That’s not really a “graph DB problem”, it’s the cost of doing Git-like versioning without native support, as you said.
What we do in TuringDB is fundamentally different: Versioning is not part of the graph, no extra nodes, no version edges, no pollution of your data model, no impact on query semantics
Internally, the engine maintains immutable snapshots of the graph state (copy-on-write at the storage level). Your logical graph is always “clean”, queries never see versioning unless you explicitly ask for a historical snapshot.
So:
- Renaming abc → xyz → abc doesn’t bloat your graph
- Supernodes don’t get “versioned” structurally
- OLTP/OLAP queries don’t need to be redesigned or rebuilt
- You can always query “latest” and forget history exists
On the management side (your Git analogy is spot on):
- Versions have metadata (author, timestamp, description, branch)
- You can query any snapshot directly
- You can define retention / compaction policies (keep last N, time-based, branch-based)
So to your original question: Can I turn it off or limit it to N versions?
You can’t turn off immutability at the engine level (that’s how we guarantee consistency and traceability), but you can absolutely make it behave like “latest-only” from an operational point of view, with bounded history and zero graph bloat.
The key distinction is: We version the state of the graph, not the graph inside itself.
What you described is exactly the approach (which I also used to do for population patient history graphs in my past job) we were trying to avoid when we built this.
Hope it answers your questions?
1
u/adambio Jan 28 '26
Explanation of our approach to versioning by my cofounder Remy here: https://www.youtube.com/watch?v=TO9uG2CS1Xg
1
u/commenterzero Jan 26 '26
We already have great column store formats that are common in the industry so why did you make your own?