Grafeo – A fast, lean, embeddable graph database built in Rust

There are 25 graph databases all going me too in the AI/LLM driven cycle.

Writing it in Rust gets visibility because of the popularity of the language on HN.

Here's why we are not doing it for LadybugDB.

Would love to explore a more gradual/incremental path.

Also focusing on just one query language: strongly typed cypher.

https://github.com/LadybugDB/ladybug/discussions/141

I just spent an hour with Grafeo, trying to also get the associated library grafeo_langchain working with a local Ollama model. Mixed results. I really like the Python Kuzu graph database, still use it even though the developers no longer support it.

Does anyone have any experience with this DB? Or context about where it came from?

From the commit history it's obvious that this is an AI coded project. It was started a few months ago, 99% of commits are from 1 contributor, and that 1 contributor has some times committed 100,000 lines of code per week. (EDIT: 200,000 lines of code in the first week)

I'm not anti-LLM, but I've done enough AI coding to know that one person submitting 100,000 lines of code a week is not doing deep thought and review on the AI output. I also know from experience that letting AI code the majority of a complex project leads to something very fragile, overly complicated, and not well thought out. I've been burned enough times by investigating projects that turned out to be AI slop with polished landing pages. In some cases the claimed benchmarks were improperly run or just hallucinated by the AI.

So is anyone actually using this? Or is this someone's personal experiment in building a resume portfolio project by letting AI run against a problem for a few months?

There seem to be a lot of these, how does it compare to Helix DB for example? Also, why would you ever want to query a database with GraphQL, for which it was explicitly not made for that purpose?

Serious question: are there any actually good and useful graph databases that people would trust in production at reasonable scale and are available as a vendor or as open source? eg. not Meta's TAO

Overwhelmed by the sheer number of graph databases? I released a new site this week that lists and categorises them. https://gdb-engines.com

The d:Document syntax looks so happy!

Interesting... Need to check how this differs from agdb, with which I had some success for a sideproject in the past.

https://github.com/agnesoft/agdb

Ah, yeah, a different query language.

This looks like another avant-garde "art" project.

I was ready to learn more about this but I saw "written in Rust" and I literally rolled my eyes and said never mind.

There seem to be a lot of these, how does it compare to Helix DB for example? Also, why would you ever want to query a database with GraphQL, for which it was explicitly not made for that purpose?

This looks like another avant-garde "art" project.

There are 25 graph databases all going me too in the AI/LLM driven cycle.

Writing it in Rust gets visibility because of the popularity of the language on HN.

Here's why we are not doing it for LadybugDB.

Would love to explore a more gradual/incremental path.

Also focusing on just one query language: strongly typed cypher.

https://github.com/LadybugDB/ladybug/discussions/141

Is LadybugDB not one of these 25 projects?

Does anyone have any experience with this DB? Or context about where it came from?

So is anyone actually using this? Or is this someone's personal experiment in building a resume portfolio project by letting AI run against a problem for a few months?

That is a lot of code for what appears to be a vanilla graph database with a conventional architecture. The thing I would be cautious about is that graph database engines in particular are known for hiding many sharp edges without a lot of subtle and sophisticated design. It isn't obvious that the necessary level of attention to detail has been paid here.

Six figures a week is a giant red flag. That kind of commit log usually means codegen slop or bulk reformatting, and even if some of it works I wouldn't trust the design, test coverage, or long-term maintenance story enough to put that DB anywhere near prod.

Agreed, there's been a literal explosion in the last 3 months of new graph databases coded from scratch, clearly largely LLM assisted. I'm having to keep track of the industry quite a bit to decide what to add support for on https://gdotv.com and frankly these days it's getting tedious.

Using a LLM coded database sounds like hell considering even major databases can have some rough edges and be painful to use.

Sounds about right for someone who ships fast and iterates. 54 days for a v0 that probably needs refactoring isn't that crazy if the dev has a real DB background. We've all seen open source projects drag on for 3 years without shipping anything, that's not necessarily better

Are you talking about Andy Pavlo bet here?

https://news.ycombinator.com/item?id=29737326

Kuzu folks took some of these discussions and implemented them. SIP, ASP joins, factorized joins and WCOJ.

Internally it's structured very similar to DuckDB, except for the differences noted above.

DuckDB 1.5 implemented sideways information passing (SIP). And LadybugDB is bringing in support for DuckDB node tables.

So the idea that graph databases have shaky internals stems primarily from pre 2021 incumbents.

4 more years to go to 2030!

Yes a graph database will happily lead you down a n^3 (or worse!) path when trying to query for a single relation if you are not wise about your indexes, etc.

Is LadybugDB not one of these 25 projects?

LadybugDB is backed by this tech (I didn't write it)

https://vldb.org/cidrdb/2023/kuzu-graph-database-management-...

You can judge for yourself what work has been done in the last 5 months. Many short videos here. New open source contributors who I didn't know before ramping up.

https://youtube.com/@ladybugdb

I'm turning off my brain and using neo4j

Using a LLM coded database sounds like hell considering even major databases can have some rough edges and be painful to use.

LadybugDB is backed by this tech (I didn't write it)

https://vldb.org/cidrdb/2023/kuzu-graph-database-management-...

You can judge for yourself what work has been done in the last 5 months. Many short videos here. New open source contributors who I didn't know before ramping up.

https://youtube.com/@ladybugdb

Yes a graph database will happily lead you down a n^3 (or worse!) path when trying to query for a single relation if you are not wise about your indexes, etc.

That sounds like a ”graph” DB which implements edges as separate tables, like building a graph in a standard SQL RDB.

If you wish to avoid that particular caveat, look for a graph DB which materializes edges within vertices/nodes. The obvious caveat there is that the edges are not normalized, which may or may not be an issue for your particulat application.

Are you talking about the query plan for scanning the rel table? Kuzu used a hash index and a join.

Trying to make it optional.

Try

explain match (a)-[b]->(c) return a.rowid, b.rowid, c.rowid;

Are you talking about Andy Pavlo bet here?

https://news.ycombinator.com/item?id=29737326

Kuzu folks took some of these discussions and implemented them. SIP, ASP joins, factorized joins and WCOJ.

Internally it's structured very similar to DuckDB, except for the differences noted above.

DuckDB 1.5 implemented sideways information passing (SIP). And LadybugDB is bringing in support for DuckDB node tables.

So the idea that graph databases have shaky internals stems primarily from pre 2021 incumbents.

4 more years to go to 2030!

I wasn't referring to the Pavlo bet but I would make the same one! Poor algorithm and architecture scalability is a serious bottleneck. I was part of a research program working on the fundamental computer science of high-scale graph databases ~15 years ago. Even back then we could show that the architectures you mention couldn't scale even in theory. Just about everyone has been re-hashing the same basic design for decades.

As I like to point out, for two decades DARPA has offered to pay many millions of dollars to anyone who can demonstrate a graph database that can handle a sparse trillion-edge graph. That data model easily fits on a single machine. No one has been able to claim the money.

Inexplicably, major advances in this area 15-20 years ago under the auspices of government programs never bled into the academic literature even though it materially improved the situation. (This case is the best example I've seen of obviously valuable advanced research that became lost for mundane reasons, which is pretty wild if you think about it.)

Source: https://www.theregister.com/2023/03/08/great_graph_debate_we...

> There are some additional optimizations that are specific to graphs that a relational DBMS needs to incorporate: [...]

This is essentially what Kuzu implemented and DuckDB tried to implement (DuckPGQ), without touching relational storage.

The jury is out on which one is a better approach.

I'm turning off my brain and using neo4j

Neo4j is pretty nice.

That sounds like a ”graph” DB which implements edges as separate tables, like building a graph in a standard SQL RDB.

Are you talking about the query plan for scanning the rel table? Kuzu used a hash index and a join.

Trying to make it optional.

Try

explain match (a)-[b]->(c) return a.rowid, b.rowid, c.rowid;

Neo4j is pretty nice.

Source: https://www.theregister.com/2023/03/08/great_graph_debate_we...

> There are some additional optimizations that are specific to graphs that a relational DBMS needs to incorporate: [...]

This is essentially what Kuzu implemented and DuckDB tried to implement (DuckPGQ), without touching relational storage.

The jury is out on which one is a better approach.

200,000 lines of code on week 1 is not a sign of a quality codebase with careful thought put into it.

> We've all seen open source projects drag on for 3 years without shipping anything, that's not necessarily better

There are more options than “never ship anything” and “use AI to slip 200,000 lines of code into a codebase”

> many millions of dollars to anyone who can demonstrate a graph database that can handle a sparse trillion-edge graph.

I wonder why no one has claimed it. It's possible to compress large graphs to 1 byte per edge via Graph reordering techniques. So a trillion scale graph becomes 1TB, which can fit into high end machines.

Obviously it won't handle high write rates and mutations well. But with Apache Arrow based compression, it's certainly possible to handle read-only and read-mostly graphs.

Also the single machine constraint feels artificial. For any columnar database written in the last 5 years, implementing object store support is tablestakes.

200,000 lines of code on week 1 is not a sign of a quality codebase with careful thought put into it.

> We've all seen open source projects drag on for 3 years without shipping anything, that's not necessarily better

There are more options than “never ship anything” and “use AI to slip 200,000 lines of code into a codebase”

> many millions of dollars to anyone who can demonstrate a graph database that can handle a sparse trillion-edge graph.

Obviously it won't handle high write rates and mutations well. But with Apache Arrow based compression, it's certainly possible to handle read-only and read-mostly graphs.

Also the single machine constraint feels artificial. For any columnar database written in the last 5 years, implementing object store support is tablestakes.

Serious question: are there any actually good and useful graph databases that people would trust in production at reasonable scale and are available as a vendor or as open source? eg. not Meta's TAO

That's a difficult question and I would like to avoid giving a direct answer (because I co-lead a nonprofit benchmarking graph databases) but even knowing what you need for a graph database can be a tricky decision. See my FOSDEM 2025 talk, where I tried to make sense of the field:

https://archive.fosdem.org/2025/schedule/event/fosdem-2025-5...

What people perceive as "Facebook production graph" is not just TAO. There is an ecosystem around it and I wrote one piece of it.

Full history here: https://www.linkedin.com/pulse/brief-history-graphs-facebook...

Serious answer: limiting to just Open Source: JanusGraph, DGraph, Apache AGE, HugeGraph, MemGraph and ArcadeDB all meet that criteria.

Yeah: Postgres, etc.

When you actually need to run graph algorithms against your relational data, you export the subset of that data into something like Grafeo (embedded mode is a big plus here) and run your analysis.

I was ready to learn more about this but I saw "written in Rust" and I literally rolled my eyes and said never mind.

The d:Document syntax looks so happy!

Interesting... Need to check how this differs from agdb, with which I had some success for a sideproject in the past.

https://github.com/agnesoft/agdb

Ah, yeah, a different query language.

I think "written by genAI" should be a bigger turnoff than "written in Rust".

Too bad you don't do the same for commenting on HN.

Overwhelmed by the sheer number of graph databases? I released a new site this week that lists and categorises them. https://gdb-engines.com

Did you generate the list using an LLM?

https://archive.fosdem.org/2025/schedule/event/fosdem-2025-5...

What people perceive as "Facebook production graph" is not just TAO. There is an ecosystem around it and I wrote one piece of it.

Full history here: https://www.linkedin.com/pulse/brief-history-graphs-facebook...

Serious answer: limiting to just Open Source: JanusGraph, DGraph, Apache AGE, HugeGraph, MemGraph and ArcadeDB all meet that criteria.

What is open source and what is a graph database are both hotly debated topics.

Author of ArcadeDB critiques many nominally open source licenses here:

https://www.linkedin.com/posts/garulli_why-arcadedb-will-nev...

What is a graph database is also relevant:

  - Does it need index free adjacency?
  - Does it need to implement compressed sparse rows?
  - Does it need to implement ACID?
  - Does translating Cypher to SQL count as a graph database?

Yeah: Postgres, etc.

When you actually need to run graph algorithms against your relational data, you export the subset of that data into something like Grafeo (embedded mode is a big plus here) and run your analysis.

Too bad you don't do the same for commenting on HN.

Did you generate the list using an LLM?

That importing is expensive and prevents you from handling billion scale graphs.

It's possible to run cypher against duckdb (soon postgres as well via duckdb's postgres extension) without having to import anything. That's a game changer when everything is in the same process.

I think "written by genAI" should be a bigger turnoff than "written in Rust".

alternative opinion:

* it is possible to write high quality software using GenAI

* not using GenAI could mean project won't be competitive in current landscape

What is open source and what is a graph database are both hotly debated topics.

Author of ArcadeDB critiques many nominally open source licenses here:

https://www.linkedin.com/posts/garulli_why-arcadedb-will-nev...

What is a graph database is also relevant:

  - Does it need index free adjacency?
  - Does it need to implement compressed sparse rows?
  - Does it need to implement ACID?
  - Does translating Cypher to SQL count as a graph database?

That importing is expensive and prevents you from handling billion scale graphs.

It's possible to run cypher against duckdb (soon postgres as well via duckdb's postgres extension) without having to import anything. That's a game changer when everything is in the same process.

alternative opinion:

* it is possible to write high quality software using GenAI

* not using GenAI could mean project won't be competitive in current landscape

> not using GenAI could mean project won't be competitive in current landscape

why? this is false in my opinion, iterating fast is not a good indicator of quality nor competitiveness

> * it is possible to write high quality software using GenAI

From examine this codebase it doesn’t appear to be written carefully with AI.

It looks like code that was promoted into existence as fast as possible.

> not using GenAI could mean project won't be competitive in current landscape

why? this is false in my opinion, iterating fast is not a good indicator of quality nor competitiveness

> * it is possible to write high quality software using GenAI

From examine this codebase it doesn’t appear to be written carefully with AI.

It looks like code that was promoted into existence as fast as possible.

Why Grafeo?¶

High Performance

Fastest graph database tested on the LDBC Social Network Benchmark, both embedded and as a server, with a lower memory footprint than other in-memory databases. Built in Rust with vectorized execution, adaptive chunking and SIMD-optimized operations.
Multi-Language Queries

GQL, Cypher, Gremlin, GraphQL, SPARQL and SQL/PGQ. Choose the query language that fits the project and expertise level.
LPG & RDF Support

Dual data model support for both Labeled Property Graphs and RDF triples. Choose the model that fits the domain.
Vector Search

HNSW-based similarity search with quantization (Scalar, Binary, Product). Combine graph traversal with semantic similarity.
Embedded or Standalone

Embed directly into applications with zero external dependencies, or run as a standalone server with REST API and web UI. From edge devices to production clusters.
Rust Core

Core database engine written in Rust with no required C dependencies. Optional allocators (jemalloc/mimalloc) and TLS use C libraries for performance. Memory-safe by design with fearless concurrency.
ACID Transactions

Full ACID compliance with MVCC-based snapshot isolation. Reliable transactions for production workloads.
Multi-Language Bindings

Python (PyO3), Node.js/TypeScript (napi-rs), Go (CGO), C (FFI), C# (.NET 8 P/Invoke), Dart (dart:ffi) and WebAssembly (wasm-bindgen). Use Grafeo from the language of choice.
Ecosystem

AI integrations (LangChain, LlamaIndex, MCP), interactive notebook widgets, browser-based graphs via WebAssembly, standalone server with web UI and benchmarking tools.

Quick Start¶

PythonRust

[](#__codelineno-0-1)uv add grafeo

[](#__codelineno-1-1)import grafeo [](#__codelineno-1-2)[](#__codelineno-1-3)# Create an in-memory database [](#__codelineno-1-4)db = grafeo.GrafeoDB() [](#__codelineno-1-5)[](#__codelineno-1-6)# Create nodes and edges [](#__codelineno-1-7)db.execute(""" [](#__codelineno-1-8) INSERT (:Person {name: 'Alix', age: 30}) [](#__codelineno-1-9) INSERT (:Person {name: 'Gus', age: 25}) [](#__codelineno-1-10)""") [](#__codelineno-1-11)[](#__codelineno-1-12)db.execute(""" [](#__codelineno-1-13) MATCH (a:Person {name: 'Alix'}), (b:Person {name: 'Gus'}) [](#__codelineno-1-14) INSERT (a)-[:KNOWS {since: 2024}]->(b) [](#__codelineno-1-15)""") [](#__codelineno-1-16)[](#__codelineno-1-17)# Query the graph [](#__codelineno-1-18)result = db.execute(""" [](#__codelineno-1-19) MATCH (p:Person)-[:KNOWS]->(friend) [](#__codelineno-1-20) RETURN p.name, friend.name [](#__codelineno-1-21)""") [](#__codelineno-1-22)[](#__codelineno-1-23)for row in result: [](#__codelineno-1-24) print(f"{row['p.name']} knows {row['friend.name']}")

[](#__codelineno-2-1)cargo add grafeo

[](#__codelineno-3-1)use grafeo::GrafeoDB; [](#__codelineno-3-2)[](#__codelineno-3-3)fn main() -> Result<(), grafeo_common::utils::error::Error> { [](#__codelineno-3-4) // Create an in-memory database [](#__codelineno-3-5) let db = GrafeoDB::new_in_memory(); [](#__codelineno-3-6) [](#__codelineno-3-7) // Create a session and execute queries [](#__codelineno-3-8) let mut session = db.session(); [](#__codelineno-3-9) [](#__codelineno-3-10) session.execute(r#" [](#__codelineno-3-11) INSERT (:Person {name: 'Alix', age: 30}) [](#__codelineno-3-12) INSERT (:Person {name: 'Gus', age: 25}) [](#__codelineno-3-13) "#)?; [](#__codelineno-3-14) [](#__codelineno-3-15) session.execute(r#" [](#__codelineno-3-16) MATCH (a:Person {name: 'Alix'}), (b:Person {name: 'Gus'}) [](#__codelineno-3-17) INSERT (a)-[:KNOWS {since: 2024}]->(b) [](#__codelineno-3-18) "#)?; [](#__codelineno-3-19) [](#__codelineno-3-20) // Query the graph [](#__codelineno-3-21) let result = session.execute(r#" [](#__codelineno-3-22) MATCH (p:Person)-[:KNOWS]->(friend) [](#__codelineno-3-23) RETURN p.name, friend.name [](#__codelineno-3-24) "#)?; [](#__codelineno-3-25) [](#__codelineno-3-26) for row in result.rows { [](#__codelineno-3-27) println!("{:?}", row); [](#__codelineno-3-28) } [](#__codelineno-3-29) [](#__codelineno-3-30) Ok(()) [](#__codelineno-3-31)}

Features¶

Dual Data Model Support¶

Grafeo supports both major graph data models with optimized storage for each:

LPG (Labeled Property Graph)RDF (Resource Description Framework)

Nodes with labels and properties
Edges with types and properties
Properties supporting rich data types
Ideal for social networks, knowledge graphs, application data
Triples: subject-predicate-object statements
SPO/POS/OSP indexes for efficient querying
W3C standard compliance
Ideal for semantic web, linked data, ontologies

Query Languages¶

Choose the query language that fits the project:

Language	Data Model	Style
GQL (default)	LPG	ISO standard, declarative pattern matching
Cypher	LPG	Neo4j-compatible, ASCII-art patterns
Gremlin	LPG	Apache TinkerPop, traversal-based
GraphQL	LPG, RDF	Schema-driven, familiar to web developers
SPARQL	RDF	W3C standard for RDF queries
SQL/PGQ	LPG	SQL:2023 GRAPH_TABLE for SQL-native graph queries

GQLCypherGremlinGraphQLSPARQL

[](#__codelineno-4-1)MATCH (me:Person {name: 'Alix'})-[:KNOWS]->(friend)-[:KNOWS]->(fof) [](#__codelineno-4-2)WHERE fof <> me [](#__codelineno-4-3)RETURN DISTINCT fof.name

[](#__codelineno-5-1)MATCH (me:Person {name: 'Alix'})-[:KNOWS]->(friend)-[:KNOWS]->(fof) [](#__codelineno-5-2)WHERE fof <> me [](#__codelineno-5-3)RETURN DISTINCT fof.name

[](#__codelineno-6-1)g.V().has('name', 'Alix').out('KNOWS').out('KNOWS'). [](#__codelineno-6-2) where(neq('me')).values('name').dedup()

[](#__codelineno-7-1){ [](#__codelineno-7-2) Person(name: "Alix") { [](#__codelineno-7-3) friends { friends { name } } [](#__codelineno-7-4) } [](#__codelineno-7-5)}

[](#__codelineno-8-1)SELECT DISTINCT ?fofName WHERE { [](#__codelineno-8-2) ?me foaf:name "Alix" . [](#__codelineno-8-3) ?me foaf:knows ?friend . [](#__codelineno-8-4) ?friend foaf:knows ?fof . [](#__codelineno-8-5) ?fof foaf:name ?fofName . [](#__codelineno-8-6) FILTER(?fof != ?me) [](#__codelineno-8-7)}

Architecture Highlights¶

Push-based execution engine with morsel-driven parallelism
Columnar storage with type-specific compression
Cost-based query optimizer with cardinality estimation
MVCC transactions with snapshot isolation
Zone maps for intelligent data skipping

Installation¶

PythonNode.jsGoRustC#DartWASM

[](#__codelineno-9-1)uv add grafeo

[](#__codelineno-10-1)npm install @grafeo-db/js

[](#__codelineno-11-1)go get github.com/GrafeoDB/grafeo/crates/bindings/go

[](#__codelineno-12-1)cargo add grafeo

[](#__codelineno-13-1)dotnet add package GrafeoDB

[](#__codelineno-14-1)# pubspec.yaml [](#__codelineno-14-2)dependencies: [](#__codelineno-14-3) grafeo: ^0.5.21

[](#__codelineno-15-1)npm install @grafeo-db/wasm

License¶

Grafeo is licensed under the Apache-2.0 License.

Hacker Times