Prolly trees have some funky properties too, for example deleting a value from a prolly tree can cause it to end up having more nodes than it started with..!! (So too can inserting a value result in fewer tree nodes)
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.
Thank you for sharing this. I've been looking into prolly trees for relay.md - I'll try swapping this in and see if i can provide any perspective for real world CRDT use cases. I'm happy to see the various key policies.
Great primitive, I’m a big fan of prolly trees! You mentioned git like filesystem snapshots? How would you retrofit that on an existing filesystem? Or you’re talking about writing a new one?
Conveniently: https://www.prollytree.com
Upon insertion do you incrementally build the tree, or do you rebuild it from scratch?
How did you ensure the distribution of nodes was about the same with the chunker?
I just used the JS splice() contract for the main API abstraction. It maps perfectly onto prolly trees since it already allows bulk insertion and deletion: https://github.com/bablr-lang/agast-helpers/blob/7225f30e5e5...
Prolly trees have some funky properties too, for example deleting a value from a prolly tree can cause it to end up having more nodes than it started with..!! (So too can inserting a value result in fewer tree nodes)
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.