I was aware of this kind of structure when I coined 'prolly tree'. It's the same thing bup was doing, which I referenced in our design docs:
https://github.com/attic-labs/noms/blob/master/doc/intro.md#...
The reason I thought a new name was warranted is that a prolly tree stores structured data (a sorted set of k/v pairs, like a b-tree), not blob data. And it has the same interface and utility as a b-tree.
Is it a huge difference? No. A pretty minor adaptation of an existing idea. But still different enough to warrant a different name IMO.
In People Keep Inventing Prolly Treesattic-labs
noms
Go2016–2025
attic-labs / noms · Archived
noms
The versioned, forkable, syncable database
33Distinct people
59Mentions
2Explicit recommenders
7.4KGitHub stars
What to know before exploring
What it is
The versioned, forkable, syncable database
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
Not much more to say other than Noms was my favorite project (https://github.com/attic-labs/noms) for a while until acquisition and the engineers are now the ones behind…
cdbattags used a recommendation phrase. 2 indexed comments match. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- dolthub/dolt · linked in 3 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year59 dated mentions
Observed mentions: 2016-08-02 16:35:18 UTC to 2025-07-01 01:04:44 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 24 | 2 | 22 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 6 | 1 | 5 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 10 | 0 | 10 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 1 | 0 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Warning - This project is not active
Noms is not being maintained. You shouldn't use it, except maybe for fun or research.
If you are interested in something like Noms, you probably want Dolt (https://github.com/dolthub/dolt) which is a fork of this project and actively maintained.
Send me (aaron at aaronboodman.com) a message if you have questions.
Use Cases | Setup | Status | Documentation | Contact
Welcome
Noms is a decentralized database philosophically descendant from the Git version control system.
Like Git, Noms is:
Versioned: By default, all previous versions of the database are retained. You can trivially track how the database evolved to its current state, easily and efficiently compare any two versions, or even rewind and branch from any previous version.
Synchronizable: Instances of a single Noms database can be disconnected from each other for any amount of time, then later reconcile their changes efficiently and correctly.
Unlike Git, Noms is a database, so it also:
Primarily stores structured data, not files and directories (see: the Noms type system)
Scales well to large amounts of data and concurrent clients
Supports atomic transactions (a single instance of Noms is CP, but Noms is typically run in production backed by S3, in which case it is "effectively CA")
Supports efficient indexes (see: Noms prolly-trees)
Features a flexible query model (see: GraphQL)
A Noms database can reside within a file system or in the cloud:
The (built-in) NBS ChunkStore implementation provides two back-ends which provide persistence for Noms databases: one for storage in a file system and one for storage in an S3 bucket.
Finally, because Noms is content-addressed, it yields a very pleasant programming model.
Working with Noms is declarative. You don't INSERT new data, UPDATE existing data, or DELETE old data. You simply declare what the data ought to be right now. If you commit the same data twice, it will be deduplicated because of content-addressing. If you commit almost the same data, only the part that is different will be written.
Use Cases
Decentralization
Because Noms is very good at sync, it makes a decent basis for rich, collaborative, fully-decentralized applications.
Mobile Offline-First Database
Embed Noms into mobile applications, making it easier to build offline-first, fully synchronizing mobile applications.
Install
Download the latest release:
Linux
Mac OS
Unzip the directory somewhere and add it to your $PATH
Verify Noms is installed correctly:
$ noms version
format version: 7.18
built from <developer build>
Run
Import some data:
go install github.com/attic-labs/noms/samples/go/csv/csv-import
curl 'https://data.cityofnewyork.us/api/views/kku6-nxdu/rows.csv?accessType=DOWNLOAD' > /tmp/data.csv
csv-import /tmp/data.csv /tmp/noms::nycdemo
Explore:
noms show /tmp/noms::nycdemo
Should show:
struct Commit {
meta: struct Meta {
date: "2017-09-19T19:33:01Z",
inputFile: "/tmp/data.csv",
},
parents: set {},
value: [ // 236 items
struct Row {
countAmericanIndian: "0",
countAsianNonHispanic: "3",
countBlackNonHispanic: "21",
countCitizenStatusTotal: "44",
countCitizenStatusUnknown: "0",
countEthnicityTotal: "44",
...
Status
Nobody is working on this right now. You shouldn't rely on it unless you're willing to take over development yourself.
Major Open Issues
These are the major things you'd probably want to fix before relying on this for most systems.
Sync performance with long commit chains (#2233)
Migration (#3363)
Garbage Collection (#3374)
Query language
We started trying to hack in GraphQL but it's incomplete and maybe not the right thing. See: ngql
Various other smaller bugs and improvements
Learn More About Noms
For the decentralized web: The Decentralized Database
Learn the basics: Technical Overview
Tour the CLI: Command-Line Interface Tour
Tour the Go API: Go SDK Tour
Contact Us
Interested in using Noms? Awesome! We would be happy to work with you to help understand whether Noms is a fit for your problem. Reach out at:
Mailing List
Twitter
Licensing
Noms is open source software, licensed by Attic Labs, Inc. under the Apache License, Version 2.0.
Read the full README on GitHubWhat Hacker News says
59 sourcesDisclaimer up front: I somewhat agree with the performance sentiment towards databases, however I feel that index performance is a different thing, because it gives you a larger budget for features further up the chain that make a meaningful non-performance difference for users, e.g. dynamic skew estimation and adaptation saving you from manual performance tuning.
To make an additional performance point about my use-case, the work I linked is not competing with on-disk databases but with in-memory datastructures like nested hash-maps and I would argue the points from the article that you linked in that scenario, but with the scales adjusted appropriately (think ns and us instead of us and ms).
To answer the question, prolly trees have a deterministic structure based on the chunking properties of their hash function. So their deterministic
Read the rest
structure is a result of using a hash to identify nodes, and only implicitly defined over the contained keys (by rolling the hash over the leafs).
Tries on the other hand, by virtue of being prefix trees, have a structure that is deterministic and directly based on the keys that they contain. This also allows you to compute a hash for each node (determined by they key range it represents) but because hashing is now orthogonal to the structure, you can choose tradeoffs more flexibly.
You can for example use an incremental hash function [1], which in my case is SipHash for the leaves and xor as a combiner (Note the importance of using a keyed hash function like SipHash when XOR is used as a combiner, see the XHASH attack in [1].)
So whenever a child is updated the new node hash can be maintained as `node.hash = (node.hash xor old_child.hash) xor new_child.hash)`.
The original Nom author actually considered PATRICA Tries and HAMTs, but dismissed unhashed prefix-tries due to bad performance. I didn't run into this yet in my use-case however, and I suspect that the overhead of string interning, indirection vs direct pointers, and more expensive hash-functions, will always outweigh in the in-memory case.
I'm still very interested in using prolly trees in the on-disk case, hence my question about latency :D
1: https://cseweb.ucsd.edu//~Mihir/papers/inchash.pdf
2: https://github.com/attic-labs/noms/blob/master/doc/intro.md#...
BTW can you point me to where the "unicit" term originates from? a quick google search only ever shows it used in your writings :D
I think rsync came first?
In the original formulation of Prolly Trees, it does reference rsync.
https://github.com/attic-labs/noms/blob/master/doc/intro.md#...
In Prolly TreesThis is from 2022. It is based on Noms [1], which is no longer maintained (they forked it).
I think the Noms doc linked from this article [2] is clearer than the article itself. That said I sill cannot turn my head around to grasp how this entire thing work tbh. I hope they wrote a peer reviewed paper to serve the audience better.
[1] https://github.com/attic-labs/
[2] https://github.com/attic-labs/noms/blob/master/doc/intro.md#...
In How Dolt Stores Table Data (2020)Was going to say it reminded me of noms, only to realize it's a fork...
https://github.com/attic-labs/noms
In Dolt is Git for DataI am. But i know very little about CRDTs lol, so we'll see how that goes. I'm interested in converting some immutable, local-first data warehouse tooling i enjoy to a CRDT version. Prior it was more.. Git-like. Basically just Git with data structures inspired-massively from Noms[1].
The thing i've found most interesting is it appears[2] that CRDT backends need to expose CRDT flavored types to users. Which is to say how i'm writing this combines the notion of a type, say `[i32]` with how you want the merges to work. CRDT works great but based on my amateur-hour researching on the subject i don't feel you can write a single CRDT merge strategy for a single data type ala `[i32]` and have it be always correct. Applications need to indicate enough context on what makes sense for a given data type.
So yea, i agree with you. I'm interested in ma
Read the rest
king a database-like thing, backed by CRDTs, but i also have seen very few general purpose implementations with CRDTs. It feels like i'm breaking "new ground", while having no idea what i'm doing and having no intention of being an actual researcher here. I'm just making apps i enjoy heh.
[1]: https://github.com/attic-labs/noms
[2]: appears, because i could easily be wrong
Not much more to say other than Noms was my favorite project (https://github.com/attic-labs/noms) for a while until acquisition and the engineers are now the ones behind Replicache (https://replicache.dev/).
I think this is going to be the next "Realm" that works everywhere.
In Downsides of Offline FirstCheck out https://replicache.dev and https://github.com/attic-labs/noms
In Immudb 1.0 – open-source, immutable database with SQL and verified timetravelInteresting exercise!
Some pointers to related ideas:
https://en.m.wikipedia.org/wiki/Persistent_data_structure
- https://docs.datomic.com/cloud/index.html
- https://opencrux.com/
- https://github.com/attic-labs/noms
- https://researcher.watson.ibm.com/researcher/files/us-leejin...
In Git as a NoSql Database (2016)Noms might be what you’re looking for (https://github.com/attic-labs/noms). Dolt is actually a fork of Noms.
In Dolt is Git for Data: a SQL database that you can fork, clone, branch, mergePeople that are interested in a similar feature set should check out https://github.com/attic-labs/noms and the SQL fork of Noms, https://github.com/dolthub/dolt
In CondensationDB: A general-purpose distributed database with end-to-end securityWith respect to IPFS and Merkle Search Trees, can anyone "in the know" comment on how they're materially different than Probabilistic B-Trees as defined by Noms[1] and Dolt[2]? I've been playing a lot with the Noms variant (Prolly Trees) lately and have often wondered where they differ from IPFS-ish Merkle Search Trees. If at all.
[1]: https://github.com/attic-labs/noms/blob/master/doc/intro.md#...
[2]: https://www.dolthub.com/blog/2020-04-01-how-dolt-stores-tabl...
In Distributed search engines using BitTorrent and SQLiteAlas https://github.com/attic-labs/noms#status :(
> Status
> Nobody is working on this right now. You shouldn't rely on it unless you're willing to take over development yourself.
In The database I wish I hadSounds very much like noms: https://github.com/attic-labs/noms
Not sure what the status of that is since Attic Labs was acquired by Salesforce.
In The database I wish I hadSince you mentioned Dolt, I will add Noms [1], which is the original db that Dolt is based on. The folks that created Noms are working now on Replicache [2]. I started using Noms in my project and the offline first tech is really wonderful; it allows me to do some cool stuff like syncing clients only when they come online.
1. https://github.com/attic-labs/noms
2. https://replicache.dev
In Recently minted database technologies that I find intriguingShowing the 15 most recent of 59 sources. Enable JavaScript to search and browse every indexed mention.