Graph database
nodekinA graph database that fits in one file.
Written in Rust. It runs inside the app that uses it, or as one small server that speaks the protocol graph apps already use. Pre-alpha, and we say so.
What it promises- Language
- Rust
- Storage
- One file per database
- Speaks
- Bolt
- Status
- Pre-alpha
- Image
- 30 MiB
- First answer
- 0.13 s after start
Measured 16 October 2026: Docker on a Mac with four CPUs, 300,000 nodes and 750,000 relationships.
MATCH (a:Person {name: "Ada"})-[:KNOWS]->(f)
-[:LIKES]->(t:Topic)
RETURN f.name, t.nameWhat it promises
Four promises, and how we count them.
A database earns trust with numbers, not adjectives. Each promise below comes with the test that keeps it.
- 01
One file.
Each database is one file, with its write-ahead log beside it.
- 02
Inside or beside.
A Rust library in your process, or a small server that speaks Bolt.
- 03
Familiar.
The query language graph apps already use.
- 04
Crash-safe.
Kill it mid-write; no acknowledged commit is lost.
Under the hood.What was hard, and what we did about it.
19 crates.
About 55,000 lines of Rust in 19 crates, built in October 2026.
Group commit.
Concurrent writers share one durable flush, so many small writes cost about one write to disk.
Search built in.
Fulltext ranked by BM25; vector search exact, for now.
Not built yet.
Bindings for Node, Python and C; approximate vector search; access control; replicas; change data capture; more than one database per server.
Where it is now
Pre-alpha. The Rust library and the server work today; the rest is on the list above, in that order of honesty.
If this is your problem
The answers you need are in how your data connects, and nobody can ask for them.
We would start with a diagnostic: about a week with your data and the questions you can't ask of it yet. You get a written verdict on how to model it, where it should live, and what it would take.
Next from the workshop · Etokin
Figure first, then the words.