--- title: How Cursor beat Git's scalability shortcomings | daily.dev description: Cursor built a Git repository service called Origin, powered by an internal engine named Continuity, to address Git's scalability limits at high volumes of... canonical: https://daily.dev/posts/how-cursor-beat-git-s-scalability-shortcomings-cyci0erz9 twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: How Cursor beat Git's scalability shortcomings | daily.dev og:description: Cursor built a Git repository service called Origin, powered by an internal engine named Continuity, to address Git's scalability limits at high volumes of... og:url: https://daily.dev/posts/how-cursor-beat-git-s-scalability-shortcomings-cyci0erz9 og:image: https://api.daily.dev/og/posts/cyCI0eRZ9.png og:image:alt: How Cursor beat Git's scalability shortcomings og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # How Cursor beat Git's scalability shortcomings **[DEVCLASS](https://daily.dev/sources/devclass)** · 4 min read · 0 upvotes · 0 comments ## Summary Cursor built a Git repository service called Origin, powered by an internal engine named Continuity, to address Git's scalability limits at high volumes of agent-driven commits and PRs. Rather than following GitHub's Spokes model of keeping multiple synchronized NVMe replicas of every repository, Cursor uses object storage (like AWS S3) as the source of truth via a write-ahead log, with a local NVMe copy acting as a fast cache. This avoids the synchronization overhead of quorum-based replication since only one local repository needs to sync with the WAL. Origin is currently in beta, available with paid Cursor plans. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### How does Cursor's Origin Git service use object storage instead of GitHub's Spokes replication model? Origin uploads pushes into AWS S3 as a write-ahead log capturing all changes as immutable objects, while simultaneously writing to a single local NVMe reference copy. Other replicas download changes from the WAL as needed. This avoids GitHub Spokes' requirement of synchronizing a quorum of at least three NVMe replicas, letting Origin ingest pushes as fast as local disk allows. _Track how object storage backed version control systems evolve as they move toward production on daily.dev._ ### Why does GitHub's Spokes approach to Git replication struggle to scale? Spokes keeps at least three tightly synchronized copies of every repository on NVMe disks, and the more replicas maintained, the longer synchronization takes. Git does not tolerate eventual consistency well, so quorum-based replication becomes a bottleneck as repository count grows, a problem worsened by AI agents creating vast numbers of small, often throwaway repositories. _Developers weighing git infrastructure choices follow scaling tradeoffs like these on daily.dev._ ### Why is Git's directed acyclic graph structure slow for servers that don't already have an object's SHA hash? Git stores objects in a content-addressable store indexed by SHA-1 hash, and a repository forms a directed acyclic graph of commits connected by pointers. If a server doesn't already have the requested SHA, it must walk the DAG step by step to assemble the needed objects, which becomes expensive when serving requests like packfile fetches across hundreds of millions of repositories. _Anyone debugging git performance at scale can follow architecture deep dives like this on daily.dev._ ## Similar posts on daily.dev - [Cursor Uses S3 WAL to Scale Git Storage to More than 300 Pushes per Second](https://daily.dev/posts/cursor-uses-s3-wal-to-scale-git-storage-to-more-than-300-pushes-per-second-eczigcs8g) · InfoQ · 0 upvotes · 0 comments - [Why Cursor Origin Still Needs GitHub to Boot](https://daily.dev/posts/why-cursor-origin-still-needs-github-to-boot-ncesneoey) · Medium · 0 upvotes · 0 comments --- Tags: [#career](https://daily.dev/tags/career), [#git](https://daily.dev/tags/git), [#aws-s3](https://daily.dev/tags/aws-s3) [View this post on daily.dev](https://daily.dev/posts/how-cursor-beat-git-s-scalability-shortcomings-cyci0erz9) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"How Cursor beat Git's scalability shortcomings","url":"https://daily.dev/posts/how-cursor-beat-git-s-scalability-shortcomings-cyci0erz9","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/how-cursor-beat-git-s-scalability-shortcomings-cyci0erz9"},"datePublished":"2026-08-24T13:47:31.702Z","dateModified":"2026-08-24T13:48:29.783Z","description":"Cursor built a Git repository service called Origin, powered by an internal engine named Continuity, to address Git's scalability limits at high volumes of...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/d0f10813cb28f4348af50f40698611d5?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/d0f10813cb28f4348af50f40698611d5?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"DEVCLASS","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"DEVCLASS","logo":"https://media.daily.dev/image/upload/s--quq5_zKP--/f_auto/v1732552064/logos/devclass","url":"https://daily.dev/sources/devclass"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/how-cursor-beat-git-s-scalability-shortcomings-cyci0erz9","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"career,git,aws-s3","timeRequired":"PT4M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"DEVCLASS","item":"https://daily.dev/sources/devclass"},{"@type":"ListItem","position":3,"name":"How Cursor beat Git's scalability shortcomings"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/how-cursor-beat-git-s-scalability-shortcomings-cyci0erz9#faq","mainEntity":[{"@type":"Question","name":"How does Cursor's Origin Git service use object storage instead of GitHub's Spokes replication model?","acceptedAnswer":{"@type":"Answer","text":"Origin uploads pushes into AWS S3 as a write-ahead log capturing all changes as immutable objects, while simultaneously writing to a single local NVMe reference copy. Other replicas download changes from the WAL as needed. This avoids GitHub Spokes' requirement of synchronizing a quorum of at least three NVMe replicas, letting Origin ingest pushes as fast as local disk allows. Track how object storage backed version control systems evolve as they move toward production on daily.dev."}},{"@type":"Question","name":"Why does GitHub's Spokes approach to Git replication struggle to scale?","acceptedAnswer":{"@type":"Answer","text":"Spokes keeps at least three tightly synchronized copies of every repository on NVMe disks, and the more replicas maintained, the longer synchronization takes. Git does not tolerate eventual consistency well, so quorum-based replication becomes a bottleneck as repository count grows, a problem worsened by AI agents creating vast numbers of small, often throwaway repositories. Developers weighing git infrastructure choices follow scaling tradeoffs like these on daily.dev."}},{"@type":"Question","name":"Why is Git's directed acyclic graph structure slow for servers that don't already have an object's SHA hash?","acceptedAnswer":{"@type":"Answer","text":"Git stores objects in a content-addressable store indexed by SHA-1 hash, and a repository forms a directed acyclic graph of commits connected by pointers. If a server doesn't already have the requested SHA, it must walk the DAG step by step to assemble the needed objects, which becomes expensive when serving requests like packfile fetches across hundreds of millions of repositories. Anyone debugging git performance at scale can follow architecture deep dives like this on daily.dev."}}]} ```