forhappy

I'd be super happy to collaborate, let me know if you have any feedbacks ;)

Thank you for your kind words, yes, I do have lots of ideas on top of prolly, actually I'm building some of them like crab(a serverless git remote, will be open-source soon), compass(a versioned code graph https://compass.crab.build/), trail(a low-level version control tooling for AI agent https://github.com/crabbuild/trail) silo(a versioned S3 client to make S3-compatible bucket version-controllable https://github.com/crabbuild/silo)

Prolly is a building block, there are sooo many use cases, I have the cookbook how developers can utilize prolly tree in their projects: https://github.com/crabbuild/prolly/blob/main/docs/cookbook....

I started learning and implementing the prolly tree since December 2025, the current one crabbuild/prolly might be the 4th or 5th prolly tree implementation ;)

Your articles taught me all the prolly tree knowledge, thank you so much :)

I’ve been working on Prolly, a Rust implementation of a content-addressed ordered map built on prolly tree(intro from dolthub https://www.dolthub.com/docs/architecture/storage-engine/pro...)

A prolly tree is similar to a B+ tree, but its node boundaries are determined by the data rather than by insertion order. Each node is addressed by the hash of its contents, and updates create a new root while sharing unchanged nodes with older versions.

This makes it useful when an application needs more than basic key/value storage: cheap snapshots, efficient diffs, three-way merges, deduplication, and incremental sync between replicas.

Some use cases I’m exploring include local-first applications, versioned database indexes, Git-like filesystem snapshots, agent memory and event logs, and reproducible RAG indexes where the exact data snapshot used for an answer can be recorded.

It’s a storage primitive rather than a complete database. The goal is to provide the ordered-map layer and let applications choose their own storage backend, data model, and conflict policy.

The project is still evolving, and I’d appreciate feedback—especially about real-world use cases, the API, and what is missing.

One of the main feature that Compass has while Graphify doesn't have is Compass support versioned graph powered by prolly tree:

``` compass git:(main) compass history --help Manage immutable graphs for Git revisions

Usage: compass history <COMMAND>

Commands: enable Enable eager graph history for future commits disable Stop eager history builds while retaining stored graphs timeline List commit graph-history state for timeline views change-counts Count structural graph changes between materialized revisions diff Stream an exact typed-record diff between realizations verify Validate an immutable realization and all typed roots status Show history configuration and realization status build Materialize an immutable graph for a Git revision rebuild Build a new realization for an already materialized revision list List stored graph realizations show Show metadata for one graph realization prefer Select the preferred realization for a revision export Restore a historical graph or Compass output bundle gc Inspect or reclaim unreachable history storage

Examples: compass history enable compass history build HEAD compass history status HEAD

Options: -h, --help Show this help

Tips: Run `compass help history <command>` for revision, format, and safety details. ```