GitHub hits 7,200 pushes per second in a single repo, and commenters ask who resolves conflicts

Last week at Universe, GitHub announced a new Git storage architecture. This week, the official blog shared internal test data: 5,000 agents working simultaneously in a single repository, 7,200 pushes per second, and read latency staying stable.

Let's set the context first. Over the past year, agents have changed how repositories on GitHub are used. Today, even the busiest repositories see only dozens of writes per second, concentrated in short bursts. But agents run in parallel around the clock, so bursts become sustained load. According to GitHub, traffic to top repositories has quadrupled in a few months and is still growing exponentially. At that rate, planning for the next increment makes no sense; they set their target at more than two orders of magnitude of improvement.

The key technical observation is simple: Git objects are immutable and named by content. If two writers store the same object at the same time, no coordination is needed. Within a push, the only thing that truly needs ordering is the reference update—i.e., which commit a branch points to—and that is usually only a few dozen bytes of data.

That observation is the starting point for the entire new architecture.

The architecture is called Project Rubicon. The name comes from Caesar crossing the Rubicon; the original framing is that agentic development has taken the industry past the point of no return.

The data plane has three layers. Spokes still handles routing and load balancing, doing sharding, isolation, and tenant fairness. Virtual replicas are a pool of stateless compute nodes whose local disks serve only as cache; if a node dies, it is replaced and the cache is rebuilt. The durability layer has two parts: Git objects live in Azure Blob Storage, while references and pack manifests live in a replicated log service called Ref-CAS.

Write path: a virtual replica indexes the incoming pack, uploads it to Blob Storage, and then commits a transaction to Ref-CAS to update the manifest and references. Background compaction nodes later merge packs to keep reads efficient.

Read path: a virtual replica first asks Ref-CAS for the current reference version. If the version has not changed, it returns directly without pulling any reference data. Only when it is behind does it get the latest references and the list of packs it needs to download, pull them from Blob Storage into cache, and then serve the request.

The most interesting part of this design is how Ref-CAS came to be. GitHub tried two Blob Storage–based approaches, and neither made it to the end.

Approach one: write all reference updates to a write-ahead log in a single blob. Every update is a conditional write to that same blob. Correctness is fine, and reads are cheap. But only one conditional write can be in flight at a time; even with batching, throughput tops out at a few hundred per second.

Approach two: shard references by hash across multiple blobs. Writes to different shards no longer wait on each other, raising the ceiling. But reads must check every shard, and latency is determined by the slowest one. Reads outnumber writes by several orders of magnitude, so that trade-off was not worth it.

Both approaches made it into the blog. Twitter user NotaDEV said in a reply that they tried two blob approaches and threw them away, and that they respect GitHub for writing down the failures.

The final Ref-CAS is a replicated log service purpose-built for reference updates. Each reference update is a CAS transaction committed through a quorum, locking only the references involved. Agents mostly push their own branches and don't conflict much, so they can commit in parallel. Each commit gets a log sequence number, and the repository's version is that number. On reads, the version number is compared; if nothing has changed, an empty response is returned.

Ref-CAS stores only pointers and never touches object data. Packs are uploaded to Blob Storage first, and references point only to objects that are already durable. Ordering guarantees correctness.

The compaction problem follows close behind. Every push creates a new pack, and the more packs there are, the slower queries get. In the old architecture, compaction ran on replicas serving traffic; the new architecture moves compaction to dedicated nodes that claim shards via leases, operate directly on Blob Storage, and notify virtual replicas of results through Ref-CAS. Compaction and read/write scale independently. GitHub's reported result is that the latency curve stays flat as writes rise.

So far this is all a storage-layer story. Scroll through the Twitter replies and you'll find something else.

With 5,000 agents crowded into one repository, the comments are almost all focused on the same issue. Someone asks: if two agents touch the same file, who resolves it? Someone says: at 7,200 pushes per second, merge conflict is now a weather event. Someone puts it plainly: ref updates are still last-writer-wins, so you'll get rebase storms and two agents doing the same ticket twice; my fleet handles that on top of Git with atomic claims and short leases.

That last comment is from Twitter user John Rood. He points to the problem the storage architecture does not solve—and does not intend to solve: Git reference updates are inherently last-writer-wins. When two agents push to the same branch, the later one overwrites the earlier one. The storage layer can do thousands of writes per second, but it will not tell you that another agent has already changed the same function.

The GitHub blog also mentions where things are heading: clone-free workflows, atomic commit APIs, event streams, lightweight clones, and faster history traversal. These all reduce the cost of agent work at the Git and GitHub layers. But coordination between agents—who is changing which file, who should wait for whom, and how to merge conflicts—is still something each team builds on top for itself.

The storage architecture is important, of course. 5,000 concurrent agents and 7,200 pushes per second—infrastructure at that scale is itself a threshold. Without it, the coordination problems above wouldn't even be worth discussing.

But a more practical question has already surfaced: once the number of agents is no longer limited by storage, what limits it?

The architecture is currently in limited private preview, with a broader rollout early next year. More people will then run real agent fleets on it and discover that storage really is no longer the bottleneck.

What the next bottleneck is, the comments have already answered.

References:

• Official GitHub blog: Inside GitHub's new Git storage architecture (Karthik Raman & Brian Celenza)
• Twitter discussion: replies to @github