minigraf vs oxigraph
Embedded single-file graph database in Rust with Datalog queries and bi-temporal time travel — 'SQLite for connected data with history' — running native, WASM, mobile and in the browser. — versus — Rust RDF graph database and SPARQL 1.1 engine on RocksDB, with Python (pyoxigraph), JavaScript/WASM bindings and a CLI server, plus reusable crates for RDF parsing, serialization and SPARQL.
Both are embeddable Rust graph stores with WASM builds; oxigraph speaks RDF/SPARQL, minigraf EAV facts with Datalog and time travel.
| minigraf | oxigraph | |
|---|---|---|
| Stars | 225 | 2.0k |
| Forks | 14 | 191 |
| Language | Rust | Rust |
| License | Apache-2.0 | Apache-2.0 |
| Last activity | yesterday | 2 days ago |
| Topics | knowledge-graphs, memory, storage | knowledge-graphs |
| Curated connections | 3 | 4 |
minigraf — the curator's take
Use it when an agent or app needs local graph memory with full history (what was true, and when we learned it) in one file, no server. Skip it for vector/semantic recall (no embeddings), large multi-user workloads, or if Datalog is a non-starter; on v2.x, note the multi-valued-attribute bug and write each value in its own transact.
oxigraph — the curator's take
The default embeddable triple store when your knowledge graph is RDF: standards-compliant SPARQL query, update and federation, every major RDF format, preliminary RDF 1.2, and it runs in-process from Rust, Python or the browser via WASM, or as a SPARQL server. Its parsers and SPARQL crates are reusable on their own, and open-ontologies uses it as its store. The README states SPARQL evaluation is not optimized yet, so for billion-triple analytics look at a heavier store. If your graph is property-graph shaped (labels, properties, Cypher), you want a different database entirely.