explaingit

attic-labs/noms

7,425GoAudience · developerComplexity · 3/5LicenseSetup · hard

TLDR

Noms was a Git-like database where every data change was versioned, branchable, and mergeable, it is archived and no longer maintained, the README points to Dolt as the active successor built on the same ideas.

Mindmap

mindmap
  root((noms))
  What it was
    Git-like database
    Full version history
    Offline-first sync
  Key concepts
    Content addressing
    Branching
    Merging
  Tech stack
    Go
    Amazon S3
    GraphQL
  Status
    Archived unmaintained
    Dolt is successor
Click or tap to explore — scroll the page freely

Code map

Detail Auto

An interactive map of this repo's files and how they connect — its source is parsed live in your browser. Click Visualize to build it.

filefunction / class

Things people build with this

USE CASE 1

Read the codebase to understand how a content-addressed versioned database was designed for offline-first apps

USE CASE 2

Study the Go implementation as background for understanding Dolt, the maintained project that succeeded Noms

USE CASE 3

Explore how database branching and merging works as a concept before evaluating Dolt for a real project

Tech stack

GoAmazon S3GraphQL

Getting it running

Difficulty · hard Time to first run · 1day+

Project is archived and unmaintained with unresolved sync and garbage collection issues, use Dolt instead for production use.

Available under Apache 2.0, free to use, modify, and distribute for any purpose including commercial, with attribution required.

In plain English

Noms is an archived database project that is no longer maintained. The README opens with a clear warning: you should not rely on this for any real-world use. If you want something that builds on the same ideas and is actively developed, the README points you to Dolt, which is a fork of Noms that has continued evolving. When it was active, Noms was designed to work like the version control system Git, but for structured data rather than code files. Just as Git keeps a full history of every change to a codebase, Noms kept every version of a database. You could go back to any earlier state, compare two points in time, or branch off from a past version to experiment without affecting the main data. Multiple copies of a Noms database could be disconnected from each other, then later merged together, in much the same way that developers working offline can later sync their code changes. Unlike a traditional database where you write commands to insert, update, or delete rows, Noms used a declarative approach. You described what the data should look like right now, and the system figured out what changed and stored only the differences. Because every piece of data was identified by its content rather than a location, writing the same data twice would not create duplicates. Noms supported storing data either in a local file system or in Amazon S3. It also included experimental support for querying data using GraphQL, though that part of the project was described as incomplete. The intended use cases were decentralized collaborative applications and mobile apps that need to work offline and then sync up when a connection is available. None of these reached production readiness before development stopped. The code is written in Go and is available under the Apache 2.0 open source license. Known issues around sync performance, data migration, and garbage collection were never resolved.

Copy-paste prompts

Prompt 1
Explain how Noms stored data using content-addressed chunks and how that enabled automatic deduplication
Prompt 2
How did Noms handle offline-first sync and merging compared to other eventual-consistency approaches?
Prompt 3
Walk me through the key Go packages in the Noms repository to show how branching and merging of structured data was implemented
Prompt 4
What unsolved problems in Noms led to the creation of Dolt and how did Dolt address them?
Open on GitHub → Explain another repo

← attic-labs on gitmyhub — every repo by this author, as a profile.

Verify against the repo before relying on details.