Scaling Git at Any Scale — Cursor's Continuity Storage Architecture

Why Git Server Scaling Has Always Been Difficult

Git is simple locally, but scaling in servers is structurally challenging. Code and metadata are stored in a binary format called packfile, and push and fetch revolve around this packfile unit. This format is efficient on local disks but has many drawbacks in server environments. Objects aren't sorted in DAG order and are distributed for size minimization, so packfiles are structurally unsuitable for logical and physical read patterns. Actual Git operations follow checkout → tree → blob → checkout cycles, but in packfile-based servers, this process doesn't align well with network file systems, causing severe performance degradation.

GitHub tried various approaches to solve this: distributed filesystems like NFS, GFS, DRBD all failed to solve the concurrent access pattern to packfiles, eventually shifting to accessing packfiles via RPC on dedicated file servers. That approach is called Spokes. Spokes doesn't distribute Git itself but copies in packfile units, keeping one Git repository per replica on NVMe disks and synchronizing with 3-phase commit. This design lasted 13 years as an industry standard, but cracks appeared in 2026 usage patterns. This path can be confirmed in Cursor's blog post Git at Any Scale and GeekNews' article How to Scale Git at Any Scale.

Spokes' Structure and 3PC's Limitations

Spokes had three choices. First, operate only in packfile units to maintain compatibility with Git clients. Second, keep actual Git repositories on local NVMe to maintain clone and fetch speed. Third, synchronize all replicas strongly.

But this basic structure had limits in extensibility. While 3 replicas per storage were sufficient, today's large monorepos require more replicas due to CI load. Since Spokes uses 3PC, each phase's latency is determined by the slowest server in the cluster. As replication volume increases, push processing capacity decreases, so there's a ceiling for large storage.

The opposite problem exists. AI agents often create many small temporary stores in monorepos, and Spokes must maintain at least 3 replicas even for these stores. While most are in a suspended state, having 3 replicas for small stores is a waste of disk and performance. Reducing replica count risks consistency. Spokes is too heavy for large storage and too complex for small storage.

When all disk storage becomes the source of truth, all replica positions, checksums, and health must be monitored via external heartbeat tables. Even a single corrupted replica causes the entire system to collapse due to consistency issues.

Continuity: A Design That Makes WAL the Source of Truth for Storage

Cursor's Continuity introduces a different approach while keeping Spokes' strengths. The core idea is to make the Write-Ahead Log (WAL) of the S3-compatible object storage the system's sole source of truth.

When a push comes in, it uploads a WAL item to S3 while writing the packfile to disk. The key point is that WAL items are fully replicated before responding to push success. Afterwards, a reference transaction is prepared in the local Git repository, and the corresponding entry must be added to each replica's WAL index object for the push to actually appear. This index update is protected by S3's atomic compare-and-swap, so conflicts don't cause inconsistencies. As a result, even if disk corruption or network partition occurs, replicating just the WAL preserves consistency.

Cost Issues in Small Storage Operation

Spokes is light per large storage but burdensome for small ones. AI agents often create many small temporary stores in monorepos, and Spokes must maintain at least 3 replicas for these too. This trades disk and performance. Continuity can adjust replica count per storage. With just WAL, replication is possible, so small stores can run with 1 replica, and large stores can be configured to run tens or hundreds of replicas strongly. This is an approach impossible in traditional hub-hosted systems.

Changes in Consistency Replication and Operational Complexity

In Spokes, the disk itself is the source of truth, so disk corruption spreads like a virus. Administrators must scan all replicas of the corresponding storage, and if they want to read data during synchronization, they had to sacrifice consistency.

With Continuity, disks are recoverable as long as the WAL is replicated. The read path comes from multiple replicas in parallel, so even if one replica lags, overall performance doesn't drop sharply. New operational overhead appears: WAL compression, index consistency checks, S3 latency estimation, but this is lighter than disk-based hub-hosted system's operational burden and cost.

Points to Consider in Practice

Continuity moves the mirror of Git storage from disk to object storage. This is a paradigm shift Git is undertaking. Git clients still operate based on local packfiles and ref transactions, but server-side must fundamentally be redesigned with object storage and WAL at its core. Existing Git compatibility must be maintained while server extensibility is essential.

Whether and how Cursor internally applies this structure, how WAL compression and index management operate, remains unpublished. But when Spokes' limitations become clearer, making WAL the source of truth appears to be a very compelling direction. If you're considering Git hosting design, it's an architecture worth checking.