DeltaDB: Next-Generation Version Control from Zed

Zed Industries announced DeltaDB on June 11, 2026, in a blog post by CEO Nathan Sobo: a new version control system built on a fundamentally different abstraction than Git — operations (deltas) instead of commits.

> "Software now takes shape in the conversation, not the commit. DeltaDB is the version control built for that."

The Problem with Commits

Git stores history as a DAG of snapshots. Everything between commits — exploration, debugging, and especially AI agent dialogues — is lost. Sobo argues:

> "GitHub doesn't let you talk about code until after you commit and push, but by then our most important conversations are usually already over."

Pull requests, in this view, exist only to reattach discussion to code after the fact because discussion and code lived in separate places.

Core Design

DeltaDB rests on three pillars:

1. Operation stream: every edit is a delta with a stable, addressable identity, captured automatically rather than via manual commits. 2. Message-edit pairing: agent messages and the edits they produced are stored side by side, so neither drifts from the other. Any line of code can be traced back to the conversation that produced it — and vice versa. 3. Conflict-free Replicated Worktrees (CRWT): multiple people and agents can edit the same files concurrently across machines, with merges converging automatically.

CRDT Foundations

DeltaDB uses operation-based CRDTs (after Shapiro et al., 2011), which require updates to be commutative and associative:

> "The conflict-free property of DeltaDB's concurrent editing is not an engineering convenience — it is a mathematical guarantee."

References are anchored to specific deltas rather than line numbers, so a comment survives the line being moved, refactored, or surrounded by new code.

Relation to Existing Tools

• Git: DeltaDB is designed to *interoperate* with Git, not replace it. Git still runs CI and connects to the outside world; DeltaDB handles real-time collaboration around commits.
• Jujutsu (jj): similar philosophies (working copy as commit, operation log, change-based model), but at coarser granularity and not designed for AI agents.
• Yjs / Automerge / Loro: CRDT engines for collaborative buffers; DeltaDB extends CRDTs to the *full version-control storage layer*, a significantly harder engineering challenge.

Team and Funding

The effort draws on deep CRDT lineage: Sobo led Atom and Teletype for Atom (among the first production CRDT collaborative editors); co-founder Antonio Scandurra built a real-time conflict-free distributed database in Rust at Ditto. Recent hires include rust-analyzer lead Lukas Wirth and Wasmtime contributor Jakub Konka. Zed raised a $32 million Series B led by Sequoia, and plans to open-source DeltaDB with optional paid services, consistent with its editor business model.

Open Questions

The announcement leaves several issues unresolved:

• Storage growth and garbage collection (CRDT metadata/tombstones can grow without bound)
• Performance on large repositories; no benchmarks disclosed yet
• UX for managing thousands of fine-grained deltas
• Privacy of automatically serialized work-in-progress — dead ends and half-formed ideas that normally stay local
• Governance concerns: PRs also serve approval, accountability, and release gating, which CRDT convergence does not address

Timeline

| Date | Event | |------|-------| | 2026-06-11 | DeltaDB announcement (Nathan Sobo blog post) | | Coming weeks | Early beta (waitlist at <https://zed.dev/deltadb>) | | Later 2026 (projected) | Open source + paid services |

Original announcement: <https://zed.dev/blog/introducing-deltadb>