GitHub's new Git storage backend: 7,200 pushes per second to one repository in internal tests, preview now

GitHub has published the first detailed account of the new Git storage system it is building underneath github.com, and the headline figures are large: in internal tests, 5,000 agents worked on one repository at the same time and pushed to it at 7,200 pushes per second. The company says today's busiest repositories see at most a few dozen writes per second, and expects bursts of that kind to become sustained within about a year as coding agents spread. The system is in limited private preview now, with a broader rollout planned for early next year.

Key points

• GitHub's engineers Karthik Raman and Brian Celenza described the new Git storage architecture on 5 November 2026; it is in limited private preview, with broader rollout planned for early 2027.
• In GitHub's internal testing, 5,000 concurrent agents worked on a single repository and reached 7,200 pushes per second. These are test figures, not production benchmarks.
• Git objects (packs) move to Azure Blob Storage, serving machines become disposable caches, and a new replicated log service called Ref-CAS holds branch references; GitHub reports reference transactions in the tens of thousands of operations per second.
• GitHub says Git behaves the same for developers (same pushes, fetches and branches, same protections); the change is underneath.
• Traffic is the reason: The Register reports GitHub events per month rising from 218.2 billion in September 2025 to 473.3 billion in August 2026.

What happened

GitHub's engineering post is titled "Inside GitHub's new Git storage architecture". It follows an earlier GitHub blog post by Celenza that The Register covered on 9 October, reporting a 35x write improvement in early internal tests, and the Universe conference the week before, where the post says the work was announced.

The new post explains why. In the past, busy repositories were busy in bursts: a team merges a release branch, CI fires, the repository calms down. Agents change that. An agent can open a branch, push, wait for CI, push again, and many agents can do this against one repository in parallel. GitHub says each push also triggers heavy read traffic from CI, deployment systems and other agents. One repository's daily requests grew about fourfold between March and May 2026, from an average of about 44 million requests a day in March to about 181 million in May, and GitHub says growth has continued on an exponential trajectory since. It set itself a target of at least two orders of magnitude more scale than it had planned for.

Background

GitHub has run Git storage on its own system called Spokes for years. The Register describes the old design this way: a three-phase commit protocol stores full copies of a repository on multiple local disks, and each write needs a quorum of replicas to acknowledge it, so the slowest required replica limits write speed. GitHub's post adds that in the legacy design compaction (the housekeeping that merges many small packs of Git data into fewer large ones) ran on the same replicas that serve traffic, which ties storage and compute together.

The pressure has been visible in public. The Register reports GitHub's own availability reports listing 10 performance-degrading incidents in April and nine in May. It also reports 7.38 billion commits in September 2026, about five times the number a year earlier; we found no breakdown of how much of that came from agents.

Other teams reached similar conclusions. The Register notes that Cursor reworked its own storage layer, rejecting a three-phase commit in favour of an object-storage write-ahead log with an SSD cache, and that former GitHub CEO Thomas Dohmke launched Entire, a Git hosting service that offloads agent traffic to mirror repositories. The same report quotes PlanetScale CEO Sam Lambert saying he has seen companies "spend three months just preparing for events" that raise traffic by 10% or 20%, which is small next to GitHub's load.

For our earlier coverage of the demand side, see our report on the Octoverse numbers and GitHub Agentic Workflows going generally available.

How it works

GitHub says the design (internally called Project Rubicon, started in May 2026) rests on two principles: minimise coordination, and separate storage from compute. The pieces:

• Spokes keeps its jobs of routing, load balancing and placement, and serves GitHub's internal API for repository data.
• Virtual replicas are disposable compute that serve both reads and writes. Their local disks are only caches that can be rebuilt at any time, so correctness does not depend on a request reaching a particular machine.
• Compaction nodes run in the background directly against storage, so serving machines spend their resources on requests.
• Azure Blob Storage holds the Git objects: packs and read accelerators, among other data.
• Ref-CAS (reference compare-and-swap) is a dedicated replicated log service that holds the branch and tag references and the manifest of which packs belong to the repository.

A write goes like this: a virtual replica indexes the incoming pack, uploads it to Blob Storage, then commits one transaction to Ref-CAS that updates the manifest and the references. A reference therefore only ever points to objects that are already durable.

A read starts with a version check against Ref-CAS. If the replica is current, the response carries no reference list at all, so a repository that has not changed costs one comparison. If it is behind, it fetches the current references and the packs it needs.

GitHub says it tried two other ways to keep references in Blob Storage before building Ref-CAS. A single write-ahead log blob made reads cheap but limited writes to one per round trip, around the mid-hundreds per second. Several segment blobs scaled writes better, but a read had to check every segment, so reads became as slow as the slowest one. Ref-CAS instead commits each update as a quorum-backed compare-and-swap that locks only the references it touches. Most agent pushes go to separate branches and do not contend, which is why the company reports reference transactions in the tens of thousands per second.

Compaction matters because each push adds a pack, and too many packs slow lookups. Compaction nodes take leases on shards of a repository's packs, seal segments by count, size or age, merge them, check that object contents match, then publish the result and remove the inputs. Merged packs grow in tiers, which GitHub says keeps the pack count roughly flat as pushes rise. Garbage collection follows a similar pattern with dedicated workers.

The numbers

Sep 2025218.2

Aug 2026473.3

GitHub events per month (billion events)

	billion events
Sep 2025	218.2
Aug 2026	473.3

Source: The Register, 9 October 2026

Mar 202644

May 2026181

Requests per day to one busy repository (monthly average) (million requests)

	million requests
Mar 2026	44
May 2026	181

Source: GitHub engineering blog, 5 November 2026

Two things stand out. Overall events roughly doubled in eleven months, but one busy repository grew about fourfold in two. That gap is the "vertical" scaling problem the post describes: the issue is less the number of developers and more the number of agents working in one repository. The test figures (5,000 agents, 7,200 pushes per second) are aimed at exactly that case.

Every performance figure in the post, and the 35x write improvement in the earlier one, comes from GitHub's own internal tests. The Register points out that no independent benchmarks are cited, and GitHub's post says the system is in limited private preview, so nobody outside has run it at scale yet.

What it means

For developers: nothing changes in your commands. GitHub says you push, fetch and branch as before with the same protections. If you run agents or CI that hammer one repository, the practical effect should be fewer slow or failed pushes when they arrive, if the tests hold up in production. There is no switch to flip yet.

For people building agent tools: the roadmap in the post is worth reading. It lists clone-free operations, an atomic multi-file commit API and event streams, plus Git-level changes such as lightweight clones, faster history walks and better guardrails against common agent mistakes. Those are signals about how GitHub expects agents to work with repositories: through APIs, not full clones.

For competitors: Dohmke's Entire and Cursor's storage rework show that Git hosting and storage are being rebuilt around agent traffic across the industry. GitHub's answer is to keep the Git interface and replace the machinery.

A new central component: the design puts Git objects in Azure Blob Storage and every reference in Ref-CAS, a new service. The post describes it as replicated and quorum-backed, but it is also the new place where a bug would affect every write.

What we don't know yet

• Who gets into the private preview, and what the broader rollout looks like for GitHub Enterprise Server customers.
• How the system performs in production under real agent traffic rather than in internal tests.
• What share of GitHub's traffic is from agents (we found no published breakdown).
• Whether repository history on GitHub.com will be migrated in bulk or gradually.
• Any independent measurement of reliability or latency.

What to watch next

Watch for GitHub's rollout dates in early 2027, for availability reports showing whether the incident count of April and May falls, and for the roadmap items: the atomic multi-file commit API and clone-free operations are the ones that would change how agent tools are built.

Sources

• GitHub Engineering: Inside GitHub's new Git storage architecture, 5 November 2026 (primary source)
• The Register: report on GitHub's Git storage rebuild, 9 October 2026