Cursor's Git fix: object storage beats GitHub's NVMe replicas

Developers who have been burned by GitHub's system outages should take note: there is another way to manage Git at scale, and Cursor just showed how. In a recent engineering post, Cursor principal systems engineer Vicent Martí explained how the company built Origin, a Git-based repository service powered by an internal engine called Continuity, on top of object storage like Amazon S3. The approach directly challenges the industry-standard architecture that GitHub itself pioneered, and it arrives as AI agents are flooding version control systems with more code, more pull requests, and more CI runs than ever before. "Agents have fundamentally changed the way we work with software, and in many ways they've made this situation worse," Martí wrote. "More code, more PRs, more CI runs. Version control is at the core of all of this, and it is possibly the hardest thing to change overnight." A beta of Origin is now available with paid Cursor plans, and the architecture is a direct response to the scalability shortcomings that have plagued Git since its creation.

Git's core problem is that it was designed by Linus Torvalds as a content-addressable data store, where every object is indexed by the SHA-1 hash of its contents. The repository is a directed acyclic graph (DAG), with each commit as a node connected by pointers. A server can look up an object directly by its SHA, but if it doesn't have the hash, it must walk the entire DAG step by step. That means even a simple request like fetching a packfile or listing recent changes requires traversing the whole graph. Now imagine doing that for over 400 million repositories, which is the scale at which GitHub operates. GitHub's answer was Spokes, an architecture that keeps at least three tightly synchronized copies of every repository on fast NVMe disks. Spokes became the industry standard, but its limits became apparent: the more replicas you add, the longer synchronization takes, and Git does not play well with eventual consistency. The problem is compounded by AI agents, which "often operate outside of a monorepo by creating vast numbers of small repositories, many of them throwaway, and most of them barely touched," Martí noted.

Cursor's solution is to flip the model. Instead of treating replicas as the source of truth, Origin uses object storage as the foundation. Object storage, like AWS S3, gives each chunk of bits a unique identifier and files it in a single namespace, with no directories. It's cheap, has built-in redundancy, and scales practically without limit, which is why it's increasingly used as a foundation for databases, container registries, and message brokers. With Origin, pushes are uploaded to S3 in a write-ahead log (WAL), capturing all changes as immutable objects, and bundled together for faster throughput whenever possible. Simultaneously, the pushes are written to a local "reference" copy of the repository, usually on an NVMe disk. Once both actions complete, other replicas can download the changes as needed. The key insight is that you only need to synchronize the reference transaction with a single local repository, not a quorum of replicas, so the system can ingest pushes as fast as the disk allows. Git still has to do DAG traversal for many operations, but it's much better to do that locally on a fast SSD than over a network.

Martí's post is notable because he speaks from experience: he worked at GitHub through much of the last decade, when the company arrived at its current Spokes architecture. So this isn't a theoretical critique from an outsider; it's a former insider explaining why the standard approach has hit its ceiling. The shift to object storage is a significant architectural bet, and it's one that could have ripple effects across the industry. If Origin proves reliable in production, it could give Git managers a serious alternative to the NVMe-replica model, especially for teams that are tired of waiting for GitHub to resolve its outages. The question is whether object storage can handle the latency-sensitive operations that Git requires, and whether the write-ahead log approach can scale to the demands of AI-driven development workflows.

The stakes are high because Git is the backbone of modern software development, and the pressure on it is only increasing. AI agents are generating more code, more PRs, and more CI runs, and they're doing it in ways that strain traditional architectures. Cursor's approach is a bet that object storage can absorb that strain, and it's a bet that could reshape how version control is managed at scale. For now, Origin is in beta, and we'll see how it holds up in production. But if we don't see stories about Origin outages, Git managers will know to give object storage a serious look. The implications go beyond Cursor: any company running Git at scale, whether they're a startup or a Fortune 500, should be watching this experiment closely. If it works, it could mean faster, more reliable version control for everyone. If it fails, it will be a cautionary tale about the limits of even the most elegant architectural solutions.