Haematite

Storage that branches like git.

Content-addressed, branchable storage on BLAKE3-hashed prolly trees. Every write is immutable. Every fork is a single hash. Every merge walks only what changed.

What is Haematite

A database that remembers every version of your data. You can go back to any point in time, branch off to try something, and merge changes back — like version control for data, not just code.

Why not SQLite?

SQLite, LMDB, RocksDB — every embedded KV store gives you a mutable data structure with replication bolted on afterward. Haematite gives you an immutable content-addressed graph where replication is a structural consequence. Two nodes compare root hashes and exchange only the subtrees that differ. No replication log. No WAL shipping. No primary/replica distinction.

The closest comparable is Dolt — git for databases. But Dolt is a server. Haematite is an embeddable library, actor-native on the BEAM, with a WebAssembly target in development.

How it compares

Fork a database

Traditional

Copy files or hold read locks

Haematite

Record a 32-byte hash. O(1). Zero data copied.

Diff two versions

Traditional

Full scan of both datasets

Haematite

Walk only divergent subtrees. Cost proportional to changes.

Concurrent writes

Traditional

Serialised behind a single lock

Haematite

Actor-per-shard. Sharded for concurrent writes. Zero lock contention.

Sync across nodes

Traditional

WAL shipping or replication log

Haematite

Compare root hashes. Exchange only differing nodes.

Designed for the browser

Same Rust code, same API, same content hashes — with a WebAssembly target in active development. The goal: the web as a first-class storage peer, not a thin client. A tree written on a server syncs to a browser tab with identical hashes. Offline-first by design.

Apache-2.0 licensed. View on GitHub →