Forem: Aditya Mukhopadhyay

Minigraf 1.0: An Embedded Bi-Temporal Datalog Database in Rust

Aditya Mukhopadhyay — Sat, 02 May 2026 10:54:03 +0000

Today I'm releasing Minigraf 1.0 — a single-file embedded graph database written in Rust, with Datalog as its query language and bi-temporal semantics built in.

If you've ever wanted Datomic but embedded, or SQLite but for connected data with full history, this is that. One .graph file, no server, no clustering, no Java runtime. It runs natively, in WebAssembly, on Android, on iOS, and inside agent processes.

The shape of the problem

Most agent memory today is one of two things: a vector store, or a pile of JSON files. Both are wrong for the same reason — they don't model the relational structure of what an agent knows, and they don't preserve when it knew it.

A coding agent that decided last Tuesday to use Postgres over MongoDB needs to remember not just the decision, but the rationale, the alternatives considered, and what the codebase looked like at the time. A vector store can find a similar-sounding chunk; it can't reconstruct the decision graph. A JSON pile can store the data; it can't query "show me every decision motivated by performance concerns made before the v2 refactor."

That second query — graph traversal scoped by time — is what Minigraf is built for.

What 1.0 actually ships

The core query model is Datalog over EAV triples (entity-attribute-value), which is the same model Datomic and XTDB use. Minigraf's contribution is the packaging:

Bi-temporal by design. Every fact carries both transaction time (when it was recorded) and valid time (when it was true in the world). Retract a fact and the history is preserved — you can replay the database state at any past moment.
Single file, embedded. Minigraf::open("data.graph") and you're running. No daemon, no port, no config. The entire database is one file you can ship, version, or sync.
Recursive Datalog rules. Multi-hop graph traversals are native, not bolted on. Reachability, transitive closure, and path queries are one rule each.
Prepared statements. Parse and plan once, execute thousands of times with $slot bind tokens. Roughly the same ergonomics as sqlite3_prepare_v2.
Window functions in :find. sum, count, min, max, avg, rank, row_number with :over (partition-by … :order-by …). Aggregations without dropping out of Datalog.
Mobile and WASM. Native Kotlin (.aar) and Swift (.xcframework) bindings via UniFFI. Browser WASM via wasm32-unknown-unknown, server WASM via wasm32-wasip1.

use minigraf::{Minigraf, OpenOptions};

let db = OpenOptions::new().path("agent.graph").open()?;

db.execute(r#"
    (transact [[:decision-42 :decision/chose "postgres"]
               [:decision-42 :decision/considered "mongodb"]
               [:decision-42 :motivated-by :perf-concern]])
"#)?;

// What did we believe at transaction 100?
db.execute(r#"
    (query [:find ?choice
            :as-of 100
            :where [?d :decision/chose ?choice]
                   [?d :motivated-by :perf-concern]])
"#)?;

What it isn't

Minigraf is deliberately not distributed, not cluster-scale, and not client-server. It's optimised for sub-million-node graphs that live next to a single process — an agent, a mobile app, a browser tab. If you have a billion nodes and a fleet of services, you want XTDB or Neo4j. If you have an agent that needs to remember a month of decisions and replay any past state, you want Minigraf.

It's also not a time-series database. Time-series tools (InfluxDB, Prometheus) are optimised for measurements at a point in time. Minigraf is optimised for facts with full retraction history — different problem, different shape.

Why now

The bi-temporal-graph thesis isn't new. Datomic has had it since 2012; XTDB built on the idea; my own previous project, RecallGraph, was pursuing the same vision in 2019. What's new is the audience.

Agents are the use case bi-temporal databases were waiting for. An agent's memory has all the structural properties — entities with relationships, beliefs that get corrected, decisions with provenance, states that need to be reconstructed at past moments — that bi-temporal Datalog was designed for. The vector store wave gave us "find similar," but agents that reason need "what did I believe and why." Minigraf is built for that second question.

How to try it

[dependencies]
minigraf = "1.0"

Or:

cargo add minigraf

The repo is at github.com/project-minigraf/minigraf. The README has a quickstart, the wiki has a Datalog reference and a comparison page (vs XTDB, Cozo, Neo4j, SQLite), and there's a working agent memory skill at github.com/project-minigraf/temporal_reasoning that demonstrates the bi-temporal model end to end.

If you build something on Minigraf, I want to hear about it — open a Discussion on the repo or reach out directly. The next phase of the project is shaped by what people actually use it for, and 1.0 is when that conversation starts.

⭐ Star the repo if the thesis resonates — it helps surface the project to others working on similar problems.

CivicGraph is now RecallGraph

Aditya Mukhopadhyay — Thu, 01 Oct 2020 10:10:28 +0000

I had posted earlier about an open source temporal graph database that I have built, named CivicGraph.

I am thrilled to follow up on that with a lineup of exciting announcements:

CivicGraph is now renamed to RecallGraph. This was deemed necessary to avoid confusion with another identically named (but functionally different) product by Microsoft. Also, the new name serves as a useful reminder for what the product is designed to do.
RecallGraph has its own sparkling new home. Check out https://recallgraph.tech/.
There is also a dedicated documentation website, replete with concepts, terminologies and a comprehensive guide to getting started with the product. Check out https://docs.recallgraph.tech/.
New API endpoints to support advanced functionalities like purge and restore.
Built-in support for distributed tracing, based on the OpenTracing standard.
More improvements, both major and minor, all listed at https://docs.recallgraph.tech/working-with-recallgraph/changelog#1-0-0.
Support for Foxx's service linking, documented at https://recallgraph.github.io/RecallGraph/.
A community support forum hosted at Gitter.
Swagger API documentation (standalone) at https://app.swaggerhub.com/apis-docs/RecallGraph/RecallGraph/1.0.0#/.

There are still miles to go, with a long development roadmap ahead. I am indeed grateful to all of you who have supported and encouraged me to keep building and improving this project! I hope it provides productive service in your tech stack(s) some day.

CivicGraph - A versioning data store for time-variant graph data.

Aditya Mukhopadhyay — Sat, 01 Feb 2020 15:01:01 +0000

I would like to introduce an open source, Apache 2.0 licensed project of mine: https://github.com/CivicGraph/CivicGraph

CivicGraph is a versioned-graph data store - it retains all changes that its data (vertices and edges) have gone through to reach their current state. It supports point-in-time graph traversals, letting the user query any past state of the graph just as easily as the present.

It is a Foxx Microservice for ArangoDB that features VCS-like semantics in many parts of its interface, and is backed by a transactional event tracker. It is currently being developed and tested on ArangoDB v3.5, with support for v3.6 in the pipeline.

CivicGraph is a potential fit for scenarios where data is best represented as a network of vertices and edges (i.e., a graph) having the following characteristics:

Both vertices and edges can hold properties in the form of attribute/value pairs (equivalent to JSON objects).
Documents (vertices/edges) mutate within their lifespan (both in their individual attributes/values and in their relations with each other).
Past states of documents are as important as their present, necessitating retention and queryability of their change history.

Its API is split into 3 top-level categories:

Document

Create - Create single/multiple documents (vertices/edges).
Replace - Replace entire single/multiple documents with new content.
Delete - Delete single/multiple documents.
Update - Add/Update specific fields in single/multiple documents.
(Planned) Explicit Commits - Commit a document's changes separately, after it has been written to DB via other means (AQL / Core REST API / Client).
(Planned) CQRS/ES Operation Mode - Async implicit commits.

Event

Log - Fetch a log of events (commits) for a given path pattern (path determines scope of documents to pick). The log can be optionally grouped/sorted/sliced within a specified time interval.
Diff - Fetch a list of forward or reverse commands (diffs) between commits for specified documents.
(Planned) Branch/Tag - Create parallel versions of history, branching off from a specific event point of the main timeline. Also, tag specific points in branch+time for convenient future reference.
(Planned) Materialization - Point-in-time checkouts.

History

Show - Fetch a set of documents, optionally grouped/sorted/sliced, that match a given path pattern, at a given point in time.
Filter - In addition to a path pattern like in 'Show', apply an expression-based, simple/compound post-filter on the retrieved documents.
Traverse - A point-in-time traversal (walk) of a past version of the graph, with the option to apply additional post-filters to the result.

I hope some of you may find this a useful service to address several types of data modelling challenges pertaining to retention and querying of historical graph data.