Grafeo: a graph database in Rust that embeds or serves

A database you link in, or one you talk to

Grafeo is a graph database built in Rust from the ground up, for speed and low memory use. It runs embedded as a library or as a standalone server, with in-memory or persistent storage, and full ACID transactions.

That first choice, embedded or standalone, is the one that shapes everything else. Embedded means the database is a crate in your dependency tree, in the same process as your application, with no server to deploy, no connection string, and no separate process to keep alive. The documentation makes the claim in strong terms: embeddable with zero external dependencies, no JVM, no Docker, no external processes.

Standalone is the other half, and it is a different deployment shape. There is a separate grafeo-server repository for it, and the same code and the same data model are available behind a network interface. The playground at playground.grafeo.dev is the quick way to see it in a browser.

Either way, the data is a graph. Grafeo supports both the Labeled Property Graph model and the Resource Description Framework model, with storage optimised for each, and it stores both in the same database, which is unusual and is the reason the query language list is as long as it is.

The language is Rust, the licence is Apache-2.0, and the homepage is grafeo.dev. The project describes itself as a high-performance, embeddable graph database with support for LPG, RDF and all major graph query languages.

Six query languages over the same graph

The query language support is the feature that makes Grafeo different from a single-language graph database, and it is worth understanding how it is presented.

GQL, which is the ISO/IEC 39075 standard, with Unicode identifiers per the specification. Cypher, at openCypher 9.0. Gremlin, from Apache TinkerPop. GraphQL. SPARQL at W3C 1.1, with SHACL validation and a Ring Index WCOJ planner. And SQL/PGQ, the SQL:2023 part that adds property graph queries to SQL. EXPLAIN and EXPLAIN ANALYZE work across all six.

The practical consequence is that a team does not have to learn a proprietary graph language to read the data, and an existing Cypher codebase can be pointed at Grafeo without rewriting every query. The same is true for a team with SPARQL endpoints or GraphQL schemas in the wider organisation.

What you give up is a single, coherent dialect. Six languages over one store means six front ends into one query planner, and the behaviour of an edge case in one of them is not necessarily the behaviour in another. The documentation does not claim otherwise, and the feature list is explicit that the role-based access control is enforced across all six query languages, which is at least a sign that the security model was designed across the whole surface rather than bolted onto one language.

The data model side follows the same logic. LPG and RDF are different models with different assumptions, and the project says storage is optimised for each. The topic list names both LPG and RDF explicitly, along with knowledge graphs and graph analytics, which tells you the intended workloads.

Vectors live inside the graph, not beside it

The vector and AI section is the one that suggests where this project is heading, and it starts from a simple decision: the vector is a first-class type in the database, not an add-on index that lives somewhere else.

The type is stated directly, a vector value of 32-bit floats held behind an Arc slice, stored alongside the graph data:

Value::Vector(Arc<[f32]>)

On top of that sit the usual search machinery. An HNSW index gives O(log n) approximate nearest neighbour search with tunable recall. The distance functions are cosine, Euclidean, dot product and Manhattan, and they are SIMD accelerated with AVX2, SSE and NEON paths. Quantization is offered in three forms, scalar from f32 down to u8, binary at one bit, and product quantization for between 8 and 32 times compression, which is what you reach for when the vectors are large enough that memory is the constraint.

Text search is handled by BM25 with a full-text inverted index, a Unicode tokenizer and stop word removal. The two are combined by hybrid search, with Reciprocal Rank Fusion or weighted fusion to merge the result lists.

The two features that matter most for an architect are the last two in the list. Change data capture keeps before and after property snapshots, which gives you audit trails and history tracking over the graph itself. And hybrid graph plus vector queries let you combine a traversal with a similarity search in GQL or SPARQL, which is the query shape that knowledge graph and retrieval work actually needs, and which is awkward when the vector index lives in a separate system with its own network hop.

Columnar storage with a writable overlay

The performance features describe an engine built for analytics over graphs, and a few of them are worth reading closely because they explain the trade-offs.

Execution is push-based and vectorized with adaptive chunk sizing, and the documentation notes that each query runs on one thread, with parallel query execution planned. That is an honest limitation stated in the documentation rather than hidden: you get one core per query today, and the storage layer is where the throughput comes from.

Storage is columnar with dictionary, delta and RLE compression. The optimizer is cost-based with DPccp join ordering and histograms. Zone maps provide intelligent data skipping, including vector zone maps. There is transparent spilling for out-of-core processing, streaming execution for large result sets without buffering, and bloom filters for membership tests.

The piece that tells you how the write path works is the writable layered compact store: a columnar base with a mutable overlay, merged by calling recompact(). That is a classic design for a read-heavy analytical store, where writes land in an overlay and are periodically folded into the base.

It also implies something about compaction, which the documentation does not detail in the excerpt: the cost of merging and the point at which you do it are operational parameters you would need to understand for a write-heavy workload. If your workload is mostly reads over a graph that changes occasionally, the design fits. If every query writes, an overlay that must be merged is a different proposition, and that is a question to ask before committing.

Security and operations are feature flags, not add-ons

The security section is a list of Cargo features, which is both the strength and the limitation of the approach.

Encryption at rest, behind the encryption feature, uses AES-256-GCM for WAL records and .grafeo sections, with either password-based setup using Argon2id or a raw key. Role-based access control offers the Admin, ReadWrite and ReadOnly roles, enforced across all six query languages, and per-graph access grants scope an identity's access to specific named graphs. SHACL validation, behind the shacl feature, implements the W3C Shapes Constraint Language with all 28 Core constraint types and SHACL-SPARQL. Resource limits cover query timeouts, property size caps and an HNSW max_elements bound.

The operations side is equally concrete. Incremental backup and point-in-time recovery are expressed as backup_full, backup_incremental and restore_to_epoch. Prometheus metrics sit behind a metrics feature with query, transaction, session, cache and GC counters and a text export. Async storage, behind an async-storage feature, gives non-blocking WAL and snapshot I/O through tokio, and a tracing feature adds opt-in observability spans and events.

For interoperability there is a long list of export formats, Arrow IPC, Polars, pandas, GEXF for Gephi and GraphML for Cytoscape, yEd and NetworkX, and an equally long import list, CSV, JSONL, TSV, Matrix Market, Turtle and N-Triples, all with streaming loaders.

The judgement here is that a security-conscious deployment is one that turns on several features and configures them carefully, and the configuration surface is where the work is.

Seven language bindings are the adoption strategy

The binding list explains how Grafeo intends to be adopted, and it is unusually broad for a project at version 0.6.

Python through PyO3, Node.js and TypeScript through napi-rs, Go through CGO, C through FFI, C# through .NET 8 P/Invoke, Dart through dart:ffi, and WebAssembly through wasm-bindgen. The published packages match: crates.io for Rust, PyPI for Python, npm packages for the Node.js and WebAssembly bindings, NuGet for .NET, pub.dev for Dart, the Go module proxy, and a web package.

For an embedded database, the binding is not a convenience, it is the whole delivery mechanism. There is no server protocol to implement per language and no query client library to write, because the query engine is in the same address space as the caller's data. A Python team that wants graph traversal in a recommendation service does not need to run anything, and a Dart team building a desktop app does not need a database service to deploy.

The WebAssembly binding is the interesting one of the set. It means the same engine can run in a browser, which is what the playground at playground.grafeo.dev is built on, and it is the reason the storage features include memory-mapped storage with an LRU cache for large datasets, which is a browser and WASM friendly design rather than a server one.

The workspace structure shows the same layering on the Rust side, with grafeo-core, grafeo-common, grafeo-storage, grafeo-engine, grafeo-adapters, the CLI and the bindings, plus a grafeo-spec-tests crate that suggests conformance testing against the specifications.

A beta release, a high MSRV, and a benchmark claim to read carefully

The release state matters for anyone planning to depend on this. The current tag is v0.6.0-beta.1, released on 2026-10-11, following v0.5.44 on 2026-10-04 and v0.5.43 on 2026-09-27, and the last push to the repository was on 2026-10-22. The project ships fast, and it has not yet reached 1.0.

The toolchain requirements are strict. The workspace declares edition 2024 and rust-version 1.99.0, and the Python binding badge says Python 3.12 and newer:

[workspace.package]
version = "0.6.0-beta.1"
edition = "2024"
rust-version = "1.99.0"
license = "Apache-2.0"

A minimum Rust version of 1.99.0 means a recent toolchain, and the presence of a rust-toolchain.toml at the repository root means the project pins one for itself. For a team on an older pinned toolchain that is a hard blocker, not a preference.

On performance, the claim is specific and should be read with its caveats. The project says that in its own graph-bench suite, which includes workloads inspired by the LDBC Social Network Benchmark, Grafeo is the fastest tested graph database in both embedded and server configurations, while using a fraction of the memory of some of the alternatives. The benchmarks section adds the important line that these are not official LDBC Benchmark results.

So the numbers are self-measured, on workloads inspired by a standard rather than being the standard's own results, and the comparison set is whichever databases the suite includes. That is a normal thing for a project to publish, and it is not the same as an independently audited result. The repository does contain a bench-thresholds.toml, which suggests regression thresholds are enforced in continuous integration, and the benchmark suite lives in a separate graph-bench repository.

The licence is Apache-2.0, with a LICENSE file, a NOTICE file and a deny.toml for dependency policy, which is a comfortable position for either embedding or serving.

Editorial conclusion

Grafeo suits a Rust team building an application that needs graph traversal and vector similarity in the same query, and who would rather embed a library than operate a database service, or a Python or Node team that wants a graph engine with no JVM in the process. It is the wrong choice if you need a stable 1.x release, since the current tag is v0.6.0-beta.1, and it is the wrong choice if you cannot live with a minimum Rust version of 1.99.0 and a Python floor of 3.12. Verify three things before you adopt it: that the query language your team already writes is among the six supported and behaves the way you expect, that the backup and point-in-time recovery path has been exercised against your own data, and that the encryption and role model in the configuration feature flags matches the access control your deployment requires.

Frequently asked questions

Official sources

1. GrafeoDB/grafeo on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases