Zed's DeltaDB, reviewed: version control for agent context

What is DeltaDB?

DeltaDB is the database behind Delta, Zed Industries' new app for coding with agents. In the words of Delta's docs, it "records thread messages, comments, Delta worktree changes, and file edits as deltas." A delta is the smallest recorded change: a file edit, a change to the file tree, a message or a comment. Each one records who made it and where it sits in the thread's history, and you never stage or commit it yourself.

The unit of work is a thread: a conversation with an agent plus the worktree it edits. Git stays where it is. Your project still needs a Git remote, commits and pull requests still go through Git, and teammates who never open Delta see a normal repository. DeltaDB keeps everything that happens between commits.

It has rolled out in steps:

• June 11, 2026: Nathan Sobo's Software Is Made Between Commits lays out the idea.
• August 12, 2026: Delta enters private beta as a separate app, with DeltaDB underneath and "the conversation instead of the editor at the center."
• September 16, 2026: Delta public beta for macOS, Linux, Windows and the web. Zed says it turned off pull requests on Delta's own repository.
• October 27, 2026: the Delta CLI and a Claude Code plugin: run /delta share in Claude Code, and a teammate runs /delta join to pick up the same thread from their own session.
• October 29, 2026: the engineering deep dive this review is mostly based on.

Why isn't Git enough for agent workflows?

Zed's argument is that the conversation is becoming the real source of the code. Scandurra puts it this way: more and more of the clarifying that leads to code happens in conversations with agents, and that context is "trapped inside the agent harness of the week" or "compressed into a commit message that the agent wrote and that you didn't read."

Git is built around snapshots a person chooses to save. Once agents do much of the typing, that leaves gaps:

• The why is lost. A commit says what changed; the prompt and the dead ends live somewhere else, if anywhere.
• Collaboration waits for a commit. Handing a half-finished task to a teammate, or to their agent, means pasting a summary.
• Parallel agents need bookkeeping: branches and worktree directories to create and clean up.

The other side deserves a fair hearing, and Hacker News gave it one (June, August). Several developers pointed out that a commit is valuable precisely because someone curated it, and that the mess in between is thinking they don't want kept. Others asked whether this is IntelliJ's local history or Jujutsu's automatic snapshots with sync added, and some worried that saved agent chats are a gift to micromanagers. Fair questions, and DeltaDB's answers are mostly architectural, which is the interesting part.

How does DeltaDB work under the hood?

Per Scandurra's post, DeltaDB is "a collection of CRDTs, all stored locally in SQLite and linked together in a directed acyclic graph (DAG)." Every node in the graph is a delta. CRDTs (conflict-free replicated data types) let each client apply its changes locally right away and sync later, so a dropped connection doesn't stop work, and every replica that sees the same deltas ends up in the same state.

The DAG gives DeltaDB every intermediate state of a thread, which is what lets you scrub through history or rewind a thread to an earlier message and get its files back as they were. The current state is described by a frontier: the deltas at the tips of the graph. Zed says the design "closely resembles" Eg-walker, the algorithm from Joseph Gentle and Martin Kleppmann's 2024 paper.

The most interesting design choice is what they didn't use. Many CRDT systems describe a version with a version vector, a counter per writer, which makes "have I seen this change?" a cheap comparison. Zed's objection is that people and agents join and leave a thread all the time, and a version vector can never drop a writer's counter, so it only grows. A frontier's size grows with how many branches are open at once, not with how many writers there have ever been. The price is that checking whether one delta includes another means walking the graph. Zed says that's fast in practice because ancestry is stored apart from the payload, in causal order.

Deltas are small on the wire. A text edit is just the version it was made against, an offset and the inserted text: struct EditTextDelta { parent: Version, offset: usize, text: String }. If the buffer has moved on since parent, the client reconstructs that version, maps the offset to internal fragment IDs, as Zed's editor does, and applies the edit to the current state. The wire format stays independent of the CRDT's internals.

How does DeltaDB store every version without storing everything twice?

Everything lives in SQLite. The hard part is the versioned data, which has to reconstruct any version quickly, because applying a concurrent delta, scrubbing history and mounting an old worktree all depend on it.

DeltaDB caches full-state snapshots for recently used versions plus a few pinned ones. To reach any other version it walks back to the nearest cached ancestor and replays the deltas in between. To keep those snapshots affordable, the whole state is a set of copy-on-write B+ trees, so a new snapshot reuses most nodes from the previous one and only pays for the paths that changed.

The B+ tree is a variation of the SumTree from Zed's editor, with one notable change: Zed's SumTree is append-only, so an edit rebuilds every node along the cut, while DeltaDB's tree edits in place through a mutable cursor. That also tells it exactly which nodes changed, so a commit writes only those rows to one generic nodes table, with reference counts for shared nodes.

How do threads sync between people and agents?

A client can follow any number of frontiers through timelines. Starting a subagent creates a new timeline parked at the parent thread's frontier, so it can make changes in parallel and be merged back later through the shared DAG, without touching Git or making a commit to coordinate.

Timelines are also the sync mechanism. When a thread is shared, the client opens a WebSocket to the server and subscribes to the timelines it cares about. To catch up, the two sides exchange a logarithmically spaced list of versions to find a recent common ancestor, then send what's missing. After that, each new delta streams to the server and on to every subscriber. Reconnecting after time offline takes the same path.

On the server, every thread gets its own Cloudflare Durable Object. The object comes to life the first time a client connects, so creating a thread costs nothing on the server, and apart from authentication at connection time the design shares nothing between threads. Zed's docs list the rest of the backend: file contents, Git commits and history packs in Cloudflare R2, active thread deltas in Durable Objects backed by SQLite, metadata in KV and D1. Besides its multi-tenant service, Zed runs single-tenant deployments for customers who "bring their own Cloudflare", and says the design ports to any platform with an object store, Postgres for authentication and addressable single-threaded processes with their own storage.

What does building on DeltaDB look like?

Application code sees none of this. The client API has four primitives:

• Register: a last-writer-wins value.
• Map<K, V>: an add-wins map.
• Buffer: collaborative text backed by a rope.
• Worktree: a tree of files layered on Git that can be mounted anywhere on disk. It starts at a commit, and each file is either pinned to its committed blob or carries the deltas written since. A commit is itself a delta, which is what ties the DAG to Git's history.

Changing a primitive mints deltas, saved and synced for you. Primitives compose with a #[derive(Replicate)] macro; Zed's agent thread is one such struct, with a transcript: Buffer, a name: Register<String>, a worktree: Worktree and a comments: Map<u64, Comment>. Each field is a typed ID into one flat Snapshot of copy-on-write trees.

The part I found most impressive is how this stays out of the way of a native UI with an 8 ms frame budget. The main thread holds an Arc of the snapshot and mints deltas synchronously. A background writer thread saves them to SQLite, and two to four reader threads, depending on cores, upload them without waiting for the writer. Remote deltas are applied in the background and sent back, with newer local deltas replayed on top. It works because the whole state is one CRDT: the UI thread and the background are simply two concurrent clients.

For tools other than Delta itself, the Delta CLI syncs agent sessions into DeltaDB. Claude Code is supported today, with Pi listed as next, and the Claude Code plugin is open source under AGPL-3.0 as a reference for other harnesses. Delta's pricing page lists a free Personal plan for your own API keys or external agents and a $10 per month Pro plan with Zed-hosted models.

What's genuinely new here?

Each ingredient has prior art: CRDTs, operation logs, Eg-walker-style text merging, editor local history, Jujutsu's snapshots. What's new is putting them together around the agent thread instead of the file or the commit:

Two ideas stand out. First, references anchor to deltas, not line numbers, so a comment or a link from a conversation survives as the code moves under it. Zed says it's working on per-character tracking across files and versions, which Scandurra describes as "a supercharged, per-character git blame." Second, the conversation lives in the same history as the code, not in a log beside it, which is what lets a teammate's agent join with your context instead of a pasted summary.

What are the tradeoffs and open questions?

DeltaDB is in beta and Zed promises more posts, so some of these may get answers soon. As of October 29, 2026, this is what I'd want to know before betting a team on it:

• It depends on Zed's servers. The CRDTs live locally, but sharing, handoff and cross-machine sync go through Zed's Cloudflare backend. Single-tenant "bring your own Cloudflare" deployments exist; a self-hosted version on your own hardware isn't described. I couldn't find DeltaDB's own source published, only the AGPL plugin.
• Transcripts become history. Whatever ends up in a conversation, a pasted secret, customer data or an angry prompt, becomes part of the record. Zed's data storage docs say it doesn't rewrite thread or Git history, and that deleting a thread locally doesn't reliably remove copies on other devices or on its servers. Data is encrypted at rest. A reply under Zed's X post asked how a redaction would work; I haven't seen a public answer yet.
• Sharing is broad. Per the CLI page, sharing a Claude Code session publishes the thread and its files to your whole Delta organization, including tool calls with their inputs and outputs and uncommitted changes. Git-ignored files stay local.
• Storing every version has a cost. Copy-on-write trees and cached snapshots keep it manageable on the client, and Zed says server-side loading of long threads and bursts of concurrent writes in one Durable Object will be covered in future posts. Zed hasn't published numbers on storage growth or load time yet.
• Convergence isn't the same as correct. CRDTs guarantee every replica reaches the same state, not that two agents' concurrent edits to one function make sense together. The interesting question, which a reader raised under Zed's X post, is how Delta surfaces that case to a human.
• Scope. One thread is tied to Git checkouts with a remote. A Hacker News commenter asked about work that spans several repositories, and the CLI currently supports one harness, Claude Code, in the terminal or the desktop app's Code tab.

Why are Zed and Anthropic both rethinking Git?

Zed isn't alone. On October 13, 2026, Anthropic described Scion, an in-house version control system it built and moved its monorepo onto from Git in five months. Its premise: "coding is no longer the bottleneck"; the bottleneck is "all of the developer infrastructure built for human scale: source control, builds, and CI." Merged changes went from around 2,500 a day in May 2026 to over 30,000 a day in September.

The fix runs the other way from Zed's. Git gives every clone a full copy that works offline, but nearly all of Anthropic's clients are agents and jobs that are "online by definition." So Scion moves commits, merges, history and blame to the server, exposes them by API, and fetches files on demand. Anthropic reports infrastructure 200x smaller in CPU and memory than its old Git mirrors.

Scion is about volume: many agents landing changes in one huge repository, and Anthropic says it's "by no means a suitable replacement for git for general use." DeltaDB is about context: keeping the conversation behind each change, with Git left in place. The shared premise is the trend: tools built around a person typing and committing strain once agents do much of the work, so infrastructure has to change as we learn how to work with them.

What does DeltaDB mean for multiplayer AI?

Multiplayer AI is several people and several agents working from the same context, where anyone can see what was asked, what was done and what was decided. Many attempts so far share context as text: a summary, a memory file, a shared prompt. DeltaDB makes it a data structure, with identity, authorship and causal order for every change.

That matters for three things multiplayer AI keeps running into. Handoff: a teammate or their agent can continue from the real state, including uncommitted work, instead of a recap. Provenance: every change records whether a person or an agent made it, and links back to the conversation behind it. Parallelism: subagents work on their own timelines and merge back without a branch per agent. The version-vector choice is a small detail with a big implication: Zed designed for agents that come and go far more often than people.

Whether threads replace pull requests, as Zed hopes, is a bet on how teams want to review work. But the move from snapshots a person chose to a shared, replicated log of what people and agents did, alongside Anthropic replacing Git where agents outgrew it, suggests version control is being redesigned around agents, not just patched for them.

Where does Koru fit?

Briefly, since this is a review of Zed's work. Koru shares the belief that shared state should be a CRDT, for different work and a different trust model. Koru is a free, open-source workspace for thinking, writing and AI that works offline. Your workspace is stored as Loro CRDT documents on your own device, and devices sync peer to peer through iroh, free and end-to-end encrypted; if a relay is needed, it only forwards encrypted traffic and never holds your data. It's available now on Windows, macOS and Linux, and it works with the AI you choose, through MCP clients like Claude and terminal tabs for coding agents like Claude Code.

Our vision is a workspace where people and AI agents collaborate on that shared state, kept on your own devices: documents, decisions and the context agents need. That part isn't shipped yet. DeltaDB's version-vector argument is a useful warning for us too, since Loro uses version vectors for sync alongside frontiers for checkpoints (Loro docs), and agents that come and go are exactly the case that makes vectors grow. For what multiplayer AI means more broadly, see What is multiplayer AI?.

This is the first post in our Multiplayer AI Tech Review series. Next time we'll look at another piece of the stack that's changing as people and agents start working together.

Frequently asked questions