frankengraphdb: a Rust property-graph database that writes its own spec first

What frankengraphdb claims to solve, and who the claim is aimed at

The README opens with an argument about the state of the graph database market. Neo4j, it says, chose pointer-chasing on the JVM. TigerGraph chose MPP with a proprietary language. Kùzu got the query story right and then, according to the README, left the commons after Apple acquired Kùzu Inc. JanusGraph and NebulaGraph pay what the README calls a permanent impedance tax on a generic key-value underlay. The stated gap is not that any single hard problem is unsolved, but that no shipping system has composed the solutions.

That framing tells you the audience. This is not a database for someone who wants to load a CSV of suppliers and click around a graph. It is aimed at engineers who already know what worst-case-optimal joins and factorized intermediates are, and who have opinions about MVCC, temporal queries and replication. The README's own comparison table lists durability, time travel, branches, storage tiers, execution, incrementality, determinism, verification, governance and retrieval as the axes. A reader who does not care about most of those axes is not the reader this project is written for.

The honest caveat sits in the README itself, in a note the author puts before everything else: the document is written in the present tense as if the entire design in COMPREHENSIVE_PLAN_FOR_THE_DESIGN_OF_FRANKENGRAPHDB.md is fully realized. The stated reason is that the document gets trued up in place as milestones land rather than rewritten. That is a defensible documentation strategy and an unusual one. It also means every capability sentence in the README has to be read as a target, not as a report.

The commit stream is the whole architecture, not a component of it

The design's first bet is that MVCC versions, time-travel history, the replication stream, change subscriptions and git-style branches are the same mechanism: an append-only, content-addressed, RaptorQ-erasure-coded commit stream the README calls Chronicle. If that holds, time travel is not a temporal engine bolted onto a storage engine. It is a consequence of how versions are stored. The README makes exactly this claim, calling queryable history under FOR SYSTEM_TIME AS OF or BETWEEN a corollary of MVCC rather than an add-on.

The second bet, Strata, is a graph-structured LSM. Adjacency lives in three tiers: inline micro-adjacency, sorted delta blocks, and sealed compressed CSR runs. The stated intent is that one store serves transactional ingest and static-CSR-class scans, with the actual rates enforced as CI benchmark gates rather than asserted. The third bet, Loom, is one Free-Join operator family that the README says subsumes binary hash joins, worst-case-optimal multiway joins and factorized intermediates over runs that are already tries.

The remaining bets cover incremental computation (a DBSP-style Z-set engine driving recursion, materialized views, subscriptions and analytics), determinism (the same state, query and policy producing byte-identical results including order, with a plan certificate attached), and verification under a deterministic lab runtime with virtual time and seed-replayable failures. Two design constraints stand out because they are checkable. The workspace sets unsafe_code = "forbid", with named fgdb-unsafe-arena, fgdb-unsafe-simd and fgdb-unsafe-vfs crates as the ledgered boundary. And the dependency universe is closed: std plus a pinned nightly plus three owned foundations, with no serde, tokio, rocksdb, arrow, tantivy or hnswlib.

Installing frankengraphdb today: a source checkout and one example

There are no releases and no installer. The README says so directly in a comment above its first command block. What runs today comes from a source checkout, and the only documented entry point is an example binary.

git clone https://github.com/Dicklesworthstone/frankengraphdb
cd frankengraphdb
cargo run -p fgdb --example open_a_database

That is the whole documented getting-started path. The example is named open_a_database and lives under the fgdb package, so a successful run means the workspace compiled and the embedded library posture opened a store. The README does not describe the output of that example, so treat whatever it prints as the starting point for reading the crates rather than as a demonstration of the feature table.

The workspace pins its toolchain through rust-toolchain.toml and uses edition 2024, so a stable-only Rust install is not enough. The member list in Cargo.toml is the map of what exists: fgdb-chronicle, fgdb-strata, fgdb-gql, fgdb-delta-types, fgdb-sim, fgdb-calibrate, fgdb-evidence, fgdb-claim, the three fgdb-unsafe-* crates, and tools/registry-check. The same file states the rule for adding engine crates: an fgdb-* crate appears only with its first real final-abstraction slice, and there are to be no empty prototype crates. That rule is the most useful thing in the repository for judging readiness, because it means the member list is a claim about what has been built rather than about what has been designed.

Once the example runs, the natural next step is the GQL surface shown in the README. The syntax below is the README's own quick example, including the FOR SYSTEM_TIME AS OF SEQ form for reading a past commit and the SHORTEST selector over a quantified path.

CREATE GRAPH social;

INSERT (:Person {name: 'Ada',  born: 1815})
       -[:KNOWS {since: 1833}]->
       (:Person {name: 'Charles', born: 1791});

MATCH p = SHORTEST (a:Person {name: 'Ada'})-[:KNOWS]->{1,4}(b:Person)
RETURN b.name, path_length(p);

MATCH (p:Person) FOR SYSTEM_TIME AS OF SEQ 41999 RETURN p.name;

Where frankengraphdb is the wrong tool, and what the README admits

The README is unusually direct about one gap: horizontal sharding is staged as genuinely future work and is listed under Limitations. A graph that outgrows one machine is therefore outside what the design claims to handle today, and that is a hard ceiling for anyone whose data already exceeds a single node.

The second limitation is structural rather than stated. A closed dependency universe is a real engineering position, but it means the ecosystem around this project is the project. There is no serde integration to lean on for serialization, no tokio to plug into an existing async service, no arrow to hand data to an analytics stack. Every one of those bridges has to be built inside the workspace or not at all. For a team whose surrounding infrastructure is Rust plus Tokio plus Arrow, that is a substantial integration cost that the README presents as a virtue.

The third is the tense problem. Because the README describes the finished system, a reader cannot tell from the README alone which of the six bets is live, which is partially implemented, and which is a plan. The repository does carry IMPLEMENTATION_STATUS.md and a registries/ directory validated by tools/registry-check, which is the mechanism the project uses to keep claims honest. But the README itself is not a status report, and treating it as one will lead to wrong decisions.

Finally, the performance story is stated as CI-enforced benchmark gates rather than as published numbers. That is a reasonable way to run a project and a poor way to evaluate one from outside, because there is no result to compare against another engine. Anyone whose decision turns on throughput figures has nothing to read yet.

Kùzu forks and the engines this design positions itself against

The README's own comparison gives the alternatives, and the sharpest one is the Kùzu lineage. The README credits Kùzu with getting the query story right through columnar CSR, vectorization, factorization and worst-case-optimal joins, then argues that after the acquisition and the archiving of the upstream repository, community forks carry that architecture forward while inheriting its gaps. The stated difference in approach is that frankengraphdb does not treat the query engine as the whole problem: it pairs a comparable execution model with a commit stream that carries durability, temporal history, branches, replication and subscriptions as one mechanism, and with a deterministic lab runtime for verification.

That is a meaningful distinction if the gaps the README names are real for your workload. A Kùzu-style embedded engine is a simpler thing to adopt: fewer moving parts, a narrower surface, and an architecture that a fork can maintain. frankengraphdb asks you to accept a much larger design in exchange for temporal and multi-writer behaviour that the README says no engine in the space currently has.

The other named alternatives occupy different ground. Neo4j is the ergonomics-first choice with a JVM runtime. TigerGraph is the MPP choice with a proprietary language and a platform-sized footprint. Memgraph and FalkorDB are fast in-memory engines that the README characterizes as having thin durability. JanusGraph and NebulaGraph sit on a generic key-value underlay. Each of those is a shipping product with documentation, releases and operational history. frankengraphdb has a plan, a workspace, and one example binary.

Licence, upgrade cost and what the repository does not settle

The licence is the least readable part of this repository. GitHub reports it as NOASSERTION, meaning the platform could not match the LICENSE file to a known template. The README badges a LICENSE file but the text is not reproduced in the README, so the terms, the copyright holder and any redistribution conditions are unknown from this page. Anyone evaluating frankengraphdb for commercial use has to open LICENSE directly and read it, and if the terms matter, have someone qualified read it too. Nothing here should be taken as a statement about what that licence permits.

Upgrade cost is dominated by the closed dependency universe and the pinned nightly toolchain. A project that depends on std plus three owned foundations moves at the pace of those foundations, and a nightly pin means toolchain bumps are a deliberate act rather than a routine one. The upside is that there is very little third-party churn to absorb. The downside is that there is also very little third-party help when something breaks.

There is one more cost that is easy to miss. The README says the document is trued up in place as milestones land, and the workspace rule forbids empty prototype crates. Together those mean the repository is designed to be read as a moving specification. Anyone tracking it needs to follow CHANGELOG.md and IMPLEMENTATION_STATUS.md rather than re-reading the README, because the README will keep describing the target state even as the target moves closer.

Editorial conclusion

Adopt frankengraphdb only if you are willing to build a Rust workspace from source and treat the README as a specification rather than a manual: it states plainly that it is written in the present tense as if the whole design were realized. Teams that need a graph database in production this quarter should not start here, because there is no installer, no release artifact and no published benchmark result to compare against. Before committing, read COMPREHENSIVE_PLAN_FOR_THE_DESIGN_OF_FRANKENGRAPHDB.md and IMPLEMENTATION_STATUS.md side by side, then run the open_a_database example and check whether the crates you need are present in the workspace member list or still only planned.

Frequently asked questions

Official sources

1. Official README
2. Project repository