Skip to content
DeltaDB

Keep the context behind every change

The version control system that records every edit with the conversation behind it.

Get startedDownload DeltaInstall the CLI

Git keeps the commits. DeltaDB keeps everything in between.

Git records a snapshot each time you commit. DeltaDB records work as a stream of fine-grained deltas as it happens, alongside the conversation that produced it. Commits, branches, and remotes stay in Git, so you push and open pull requests as usual.

How Delta and Git work together
Git keeps the commits; DeltaDB keeps everything in between. Three Git commits on a line. Around them, the reasoning behind the work surfaces and falls away: the ask, dead ends, rationale, tradeoffs, test results, pushback. Then a DeltaDB timeline appears beneath the same commits, and that reasoning lands in it as deltas, alongside the code edits. Finally, links show a worktree starting from the first commit, and its work going back to Git as a commit and a pull request.GitA snapshot at each commit4a7c2e19d03b5fc61e8a4the askdead endsrationaletradeoffstest resultspushbackLost between commitsDeltaDBEvery step in betweenthe askdead endsrationaletradeoffstest resultspushbackKept: every message and edit, with the codeWorktreeCommitPull request

How DeltaDB works

DeltaDB records each change as it happens and keeps every copy in sync.

  1. 1

    Every edit becomes a delta

    DeltaDB records each edit, yours or an agent's, as a delta with a stable identity, its author, and the version it builds on. There's nothing to stage or commit.

    Each edit, from you or an agent, becomes one delta in the history123456Historyfn retry(attempts: u32) {You for n in 0..attempts {Agent if try_once().is_ok() { return; }Agent sleep(backoff(n)); }Agent}You
  2. 2

    The conversation shares the history

    Messages, comments, and file tree changes are deltas too, so each message sits in the same history as the edit it produced.

    Messages, code edits, comments, and file changes all land in one historyMessagesCode editsCommentsFile changesOne history
  3. 3

    Every copy stays in sync

    Every Delta client holds a replica. Deltas sync as you type, and concurrent edits resolve the same way on every machine, in any order.

    Every replica converges on the same history. A laptop, a cloud runner, and a browser each receive the same four changes through the sync server, in different orders. Each change takes its agreed place, so all three end with the same history and fingerprint.Sync serverYour laptopfingerprint 9c41 ✓Cloud runnerfingerprint 9c41 ✓Teammate's browserfingerprint 9c41 ✓
  4. 4

    Files appear where you need them

    Agents and browsers use the replicated files directly. On your machine, Delta mounts them into a checkout for your terminal, builds, and editor. The checkout is temporary, and the work stays in DeltaDB.

    Read about Delta worktrees
    One Delta worktree, used from a laptop checkout, an agent on a cloud runner, and a browserWorktreein DeltaDBCheckout on your laptopTemporaryAgent on a cloud runnerBrowser

What a continuous history makes possible

Rewind to any message

Revert a thread to an earlier message, and DeltaDB restores its files to match. You don't need a commit.

Share work before you commit it

Teammates can join while the agent is still working, read the conversation, and comment on changes before anyone commits.

Start new work without the bookkeeping

Each thread gets an isolated worktree, and you can fork one to try another approach. There are no directories or branches to clean up.

Know where each change came from

Each delta records whether a person or an agent made it. From the code, you can get back to the conversation behind it.

Under the hood

DeltaDB is built on CRDTs, loosely based on diamond-types and adapted to work with Git.

Read the deep diveWatch the talk

Each delta records what it was based on

A delta carries the text it inserts, the ranges it replaces, and the version it builds on: earlier deltas, or a Git blob for a file's starting text. Without a shared clock, order comes from the causal graph.

Each batch points to the versions it builds on. Five batches of changes from actors A and B. Two are written concurrently on the same parent; the next batch names both as its parents. Each batch's Lamport timestamp is higher than its parents'.(1, A)(2, A)(2, B)(3, A)(4, B)parents: (2, A) and (2, B)1234Lamport timestamp →
struct HistoryDeltaBatch {
    id: DeltaBatchId,
    parent: HistoryVersion,
    payloads: Vec<HistoryDelta>,
}

struct DeltaId {
    timestamp: u64,
    actor_id: ActorId,
}

Frequently asked questions

Does DeltaDB replace Git?

No. Your project still needs a Git remote, commits stay in Git, and you push and open pull requests as usual. DeltaDB records the work between commits.

What does DeltaDB record?

Messages, comments, file tree changes, and edits to files Git tracks or doesn't ignore. Ignored files, like build output and local .env files, stay on the machine that created them.

How do I use DeltaDB?

DeltaDB comes with Delta. Download the app, or open a shared thread in your browser.

Read more about DeltaDB

Open Delta