Origin, Code Storage, and DeltaDB

The shared pressure #

Git’s immutable objects form a content-addressed DAG. Objects are compressed into packfiles for storage and network transfer, while mutable refs name graph positions. That design remains an excellent compatibility layer, but naïvely distributing individual objects across a generic key-value store turns graph traversal into sequential network round trips.

Agent workloads amplify a different set of costs: many short-lived repositories, high branch fan-out, concurrent writers, repeated environment creation, and repositories that should become cold when a task ends. Origin and Code Storage preserve Git objects and protocols while changing the service architecture around them. DeltaDB moves below the snapshot level and asks what is lost when edits and conversations are reduced to commits.

Origin and Continuity #

Cursor’s earlier Spokes design kept ordinary Git repositories on local NVMe, replicated incoming packfiles, and used a three-phase commit around the reference transaction. Every replica stayed consistent, but adding replicas extended the push path, and keeping a minimum replica set was expensive for small or idle repositories.

Continuity replaces that replication floor with a write-ahead log in S3-compatible object storage. During a push, a node writes the packfile locally and uploads it as a WAL entry. The push is not acknowledged before that entry is durable, and it is not visible before the local ref transaction is prepared and the WAL index atomically points to the entry. Cursor describes pushes as linearizable: the object-store index is the ordering authority.

The local Git repository becomes a warm cache rather than the source of truth. Rendezvous hashing chooses the nodes expected to hold a repository, but an idle repository can have no hot replica. A node can materialize or catch up from the WAL; conditional reads of the index use its ETag, while UDP gossip only provides an optimistic nudge. Correctness comes from the index and catch-up path, not from gossip, leader election, or every replica participating in each write.

This separation also centralizes maintenance. A primary compacts Git data, writes the resulting packs to the WAL, and lets replicas download those packs instead of independently repacking. Cursor reports synthetic scaling results in its article, but the more durable architectural point is that capacity and durability are no longer tied to a fixed number of always-hot Git replicas.

Origin is the product layer built above this storage system: repositories, pull requests, code browsing, and agent workflows. Its current GitHub sync mode keeps GitHub as the source of truth for pushes while Origin provides browsing, search, pulls, and synchronized review comments. Continuity is the storage architecture; Origin is the forge.

Code Storage #

Code Storage starts from a similar storage problem but exposes a different product boundary: managed Git infrastructure for software that needs repositories, not another developer forge. It supports normal clone, fetch, and push endpoints alongside TypeScript, Python, and Go SDKs for manipulating repository state without maintaining a local clone.

Pierre describes the service as a Spokes-like quorum architecture using three-phase commit around Git updates, with hot and cold storage tiers. Public documentation does not expose the same WAL-level design detail as Continuity, so the safe comparison is behavioral: both preserve Git’s objects and reference updates, while Code Storage makes repository lifecycle and mutation programmable.

Authorization is designed for untrusted workers. A customer signs short-lived ES256 or RS256 JWTs containing an organization, repository, exact scopes, and expiry; Code Storage retains the public key. Read, Git write, repository administration, and organization access are separate scopes. Ref policies can further constrain branches, tags, notes, namespaces, force pushes, and signature requirements, so an agent does not need an organization-wide credential.

Namespaces make repository lifecycle explicit:

• Default endpoints behave like conventional Git remotes.
• Ephemeral endpoints share objects and access rules with the repository, but their refs are hidden from normal clones and upstream mirrors until they are promoted. That maps naturally to one branch per agent session.
• Import endpoints are push-only bulk-ingest paths. The service fans a pack to its storage nodes, queues cold storage, then removes the hot copy; a later read can thaw the repository.

The session API adds optimistic concurrency through an expected head SHA, making a stale agent update fail instead of silently replacing another result. What Code Storage intentionally does not provide is equally important: no pull requests, issues, or review UI. It is a repository substrate on which those products can be built.

DeltaDB #

DeltaDB is not a Git hosting architecture. Its primary record is a fine-grained delta: edits, agent steps, comments, and conversations with stable identities. A commit preserves a tree snapshot and parent links; a delta stream can preserve how the tree changed, who or what caused an edit, and which discussion referred to it.

Replicated worktrees use CRDTs so multiple people and agents can edit the same files and converge without serializing every operation through a central ref update. Each participant gets a local copy, while the same model can run in cloud workers or a browser through WebAssembly. This is a different consistency problem from a linearizable Git push: replicas must merge an operation stream rather than agree on one new reference value.

Stable delta identities also give review comments a stronger anchor than a line number in one diff. Zed’s design keeps code edits, agent actions, and discussion in one history, so references can survive movement and later edits instead of becoming detached context in a separate forge database.

Delta, the first DeltaDB client, still commits and pushes to an existing Git repository. Collaborators outside Delta see ordinary Git history. Git is therefore an export and interoperability boundary, not DeltaDB’s internal collaboration model.

What actually differs #

Origin and Code Storage compete most directly at the repository-storage layer, although one arrives as a forge and the other as infrastructure. DeltaDB can sit beside either because it retains information that neither Git service attempts to model.

Where jj fits #

Jujutsu separates its commit backend, operation backend, operation heads, index, and working copy behind storage-independent APIs. In the public build, the production backend is GitBackend: it uses Git objects and object IDs, while jj stores additional change identity and predecessor metadata alongside them and keeps its operation history separately. SimpleBackend proves the commit interface can use another format, but it is a proof of concept that stores one file per object—not a hosted remote.

There is a real jj-native server inside Google. The jj roadmap describes an internal database-backed service that stores commits and repository operation logs in the cloud, with a local daemon caching reads, prefetching data, and optimistically acknowledging writes. That backend and service are private to Google.

No equivalent public jj-native server or remote protocol ships today. Public jj repositories normally cross the network through Git remotes, which share Git commits and refs but not the complete local operation log or every jj-specific identity. A future public service can follow the Google architecture without making Git’s object model the permanent center of jj.

JayJay, briefly #

JayJay sits above these storage choices and presents jj changes, bookmarks, revsets, conflicts, and local review state. Origin could become another forge adapter, Code Storage already fits as a generic Git remote, and DeltaDB would be a separate live-collaboration integration. None should redefine the app around Git commits merely because Git is today’s public transport.

Further reading #

• Git at any scale and Origin code hosting — Continuity and the forge built on it.
• Code Storage and its documentation — managed Git infrastructure for agents.
• Introducing DeltaDB and Introducing Delta — the replicated edit stream and its first app.
• jj architecture and the jj roadmap — public backends and Google’s internal server architecture.