Some new database technologies released this year on Github are starting to explore new ideas along these lines including
https://github.com/attic-labs/noms
Which is using the concept of Prolly Trees
https://github.com/attic-labs/noms/blob/master/doc/intro.md#...
Which are Probabilistic B-Trees...
In General and Fractional Hypertree Decompositions: Hard and Easy Cases (2016) [pdf]attic-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 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 5:05:26 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
24 sourcesWe want to. It would be nice if we could just use cgo but it's not complete. So we need to build some kind of simplified API to Noms that can be exported via cgo.
I created a bug for this just now: https://github.com/attic-labs/noms/issues/2718
Please feel free to get involved there.
In Noms – A versioned, forkable, syncable databaseWe haven't implemented access control yet. See https://github.com/attic-labs/noms/issues/1183 for one idea.
In Noms – A versioned, forkable, syncable databaseThe claim on the website is not meant to suggest that any two changes can be automatically merged. I will try to clarify that.
The world contains logical conflicts because physical constraints mean that processes can operate disconnected from each other. No database can wave that away.
Noms will automatically, efficiently, and correctly merge changes that don't logically conflict. Which is a pretty cool and unique property in a database.
If any conflicts are found, there is a callback to user software to perform a resolution.
More info in the documentation:
https://godoc.org/github.com/attic-labs/noms/go/merge
In Noms – A versioned, forkable, syncable databaseOpen-source tech like this is nice. This could be used to build a distributed document editing application, for example. Or any application where you want to spin off multiple instances and reconcile the data later.
EDIT: At least one team is investigating layering Noms on top of IPFS [1]. I guess the idea would be to construct something similar to GitTorrent [2]; layering various version-controlled datastores on various p2p protocols could result in several viable architectures.
[1] https://github.com/attic-labs/noms/issues/2123#issuecomment-...
[2] https://github.com/cjb/GitTorrent
In Noms – A versioned, forkable, syncable databaseNoms – A versioned, forkable, syncable database
399 points · Open discussionYou should take a look at Noms:
https://github.com/attic-labs/noms
Happy to answer questions here or in our Slack channel.
In Vanadium – Create distributed applications that can run anywhereIf you did the tech startup, what would you like your role be?
Would you be the product guy, designing screen flows, talking to users, figuring out how to solve people's problems? Would you be the biz guy, doing deals and making sales? Would you be the technical architect, staying up late hacking away?
===
If you love (and notice I keep using the word "love", consciously) programming, then it's just a matter of interview anxiety. That is solvable. Some great companies don't do standard whiteboard interviews. You could focus on those. You can also bolster your overall hireability by participating in open source projects (my project - https://github.com/attic-labs/noms - is always looking for contributors) and publishing code on github.
At my startup we don't do whiteboard interviews for exactly this reason - lots of people just suck at the
Read the rest
m. It doesn't give you a good signal. More and more smallcos are going this direction.
===
If what you really love is product design, or business development, or sales, then you can try and get work doing that. I am aware of people who have totally hustled their way into great companies as bizdev or product by just doing what needed to be done before even getting hired ("hey, I found you a customer -- btw can I have a job??").
This also can work for engineers btw. "hey, I fixed this bug for you, btw can I have a job??".
When I was at Google, we had a guy show up to one of the OSS projects. He started sending in patches, participating in the mailing list, making design proposals. We hired him. It largely wouldn't have mattered how he did on the interviews, it was clear he was a star before he walked in the door.
===
I would also note that you don't need to go to one of the big-four to get connections for a future thing. Tech is very close-knit. People cycle in and out of bigcos and tinycos all the time.
It's infinitely more important how much impact you make, than where you are. Change the fate of a small company and everyone there will love you and sing your praises. You'll have opportunities from all those people's direct and indirect connections.
Go to a bigco, and it is actually harder to make as big an impact. You'll know more people directly, maybe, but it will be harder to really impress them.
===
Good luck, again. I've been where you are. It sucks, but you'll get through it.
Try to focus on what you want, then put one foot in front of the other to get there :).
How does this compare with, say, noms? https://github.com/attic-labs/noms
In Academic Torrents: A distributed system for sharing enormous datasetsIt would not be hard to do an encrypted remote.
We already have to support moving between different versions of the noms format, which changes all the hashes. Encryption is the same. You can look at an encrypted remote as just a different version of the format, and use the same approach.
Star this bug, and when the migrate program is landed, you could basically just fork it to support encryption:
https://github.com/attic-labs/noms/issues/2272
In Show HN: A FUSE Filesystem on NomsNot implemented yet, but here is the plan: https://github.com/attic-labs/noms/issues/148
In Show HN: Noms – A new decentralized database based on ideas from Git- Type accretion: I don't think in general that schema changes like what happens in sql databases works very well (I say this having worked on such systems). In big systems, it's hard to get everyone to agree on a moment to CHANGE THE SCHEMA. You can certainly do something like that in Noms -- just write a new dataset and replace the old one. But being able to read old data and leave old clients working I think is powerful. Couple this with the structural typing that falls naturally out of Noms and - I think - you have a more flexible way to change schemas over time.
- Security: current thoughts: https://github.com/attic-labs/noms/issues/1183
- Perf: I'm not really following you here. CAS has some positives and some negatives for performance.
- expiration: 1. there are a huge number of systems today that never delete data. Taking advantag
Read the rest
e of that to make other operations faster makes sense. 2. yeah, it's a gc problem. luckily gc is a well-studied problem. Also, as Noms is a merkle tree and merkle trees are good at diff, we have some additional leverage. We don't need to do a full scan everytime.
- querying: disagree that it is essential to perf. Another option is to have a schema that matches your access model. You can do that server-side in addition (or instead) of having a query language.
===
It sounds like you have thought a lot about all of this! If you are interested, your brain would be very appreciated in the github or slack.
We have implemented a bunch of importers. One of them is CSV. Take a look at https://github.com/attic-labs/noms/tree/master/samples/go/cs...
We envision there to be tools that work on certain data types (Noms has a full type system), for example an app that displays all geo locations in a dataset.
In Show HN: Noms – A new decentralized database based on ideas from GitThanks for the help everyone with this most important aspect of the system ;).
To clarify, we don't think of these specs as URLs. The part before the final double-colon is a URL. To parse one, you get the final double colon, and take everything to the left as a URL.
There's some info on the syntax here:
https://github.com/attic-labs/noms/blob/master/doc/spelling....
Though it's not presented as a formal grammar in that doc, our most important criteria for the syntax was:
- unambiguousness
- interacts well with the shell, since we frequently use these as part of command lines
In Show HN: Noms – A new decentralized database based on ideas from GitShowing the 15 most recent of 24 sources. Enable JavaScript to search and browse every indexed mention.