This isn't a new Git feature or a setting you can change. It's plumbing. But it affects anyone running CI fleets, merge queues or AI coding agents against GitHub.
Why GitHub is doing this now
GitHub ties the timing to the shift toward agent-driven development. It cites rapidly growing traffic, a hard ceiling on data center power capacity and the surrounding region, and physical supply chain constraints. It also says that changing the storage architecture and the hosting platform at once was too risky. So the plan was to move the data first and evolve the architecture afterward.
The scale is real. In a separate October 6 post, GitHub reported monthly Git activity above 473.3 billion events, pushes up 4.9x to 3.35 billion a month, and 7.38 billion commits in a single month.
Git operations are a Tier 0 service, meaning nearly everything on GitHub depends on repository data. That is why the data and its dependencies had to move first.
How traffic moves to Azure
Most repositories keep five replicas. Spokes is GitHub's repository storage and routing layer. It uses preferential routing to send traffic to a replica in the same region and availability zone as the request. As replicas move to Azure, more traffic can be served from Azure. When the last replica arrives, the old region stops receiving requests.
That is how GitHub moved capacity without asking repository owners to do anything. Per the October 21 post, Azure absorbed growth for most of that time while GitHub's own data centers held steady.
The 25 ms problem
The current quorum design has a flaw that only shows up across regions. Spokes' quorum needs only a majority to commit a write, but it waits for every healthy replica to respond, up to a timeout. So the slowest healthy replica sets the latency of every write. Each write also holds a repository-wide lock until it commits, so that latency becomes the throughput ceiling too.
GitHub says an Azure replica is about 1,000 miles from its data centers. That makes each round trip about 25 ms, and one write needs several of them. For a quiet repository this doesn't matter. For one already near its ceiling, each push falls further behind and the queue grows.
The fix: serialize per reference
GitHub's answer follows its "minimize coordination" principle. Git's consistency rule applies to each reference on its own. Once the server accepts an update to a reference, no client should see an older value afterward. That holds for fast-forwards, force pushes and deletes. Updates to different references usually don't depend on each other.
| Model | What is serialized | Effect |
|---|---|---|
| Repository-wide quorum | The entire repository, one write in flight | The slowest replica gates every write |
| Per-reference quorum | Each individual reference | Writes to different references overlap their waits |
Concretely, a push to refs/heads/main and a push to refs/heads/agent/task-42 can commit in parallel. Two pushes to refs/heads/main still wait for each other. Each write still pays the cross-region latency. The difference is that independent writes pay it at the same time.
GitHub reports that internal tests with realistic traffic showed 3–4x higher throughput at lower latency for writes to different references. That is GitHub's own measurement, not an independent benchmark. The gain scales with how many references are being written at once. A workload that funnels everything into one branch gets no such benefit.
Splitting reads from writes with virtual replicas
Most repositories see roughly 100 to 1,000 reads per write. Today reads and writes share the same replicas, so they compete for memory and CPU. GitHub's next step is to put Azure Blob Storage into the quorum through what it calls a virtual replica.
- Virtual write replica. This is GitHub's first fully ephemeral node. It streams writes to object storage and serves no reads. Because it sits in the quorum, a write isn't acknowledged until it is durable in object storage. It adds a little latency per write. It also coalesces updates to disjoint references into one set of storage I/O, and for now it handles compaction.
- Virtual read replicas. Once the write path exists, GitHub can add as many of these as a repository needs. They warm a cache from Blob Storage, serve reads outside the quorum, and reconcile against object storage in the background.
GitHub says its distributed load-test harness routinely found ceilings in the current architecture, but against virtual read replicas the harness hit its own limits first. Again, that is internal testing.
There is a caveat. Background reconciliation suits some reads but not all. Serving every kind of read means moving reconciliation inline, fetching only the reference state and data that changed since the replica last caught up. GitHub presents that as a later step, not something already done.
What comes next
Spokes does more than coordinate writes. GitHub says it also does routing and load balancing, provides the unified API internal clients use at well over 100 billion operations per day, and runs background "sweepers" for placement, repair and rebalancing. GitHub says the commit protocol that carried it to a billion repositories won't carry it to the next billion.
The remaining limit is write throughput. Git objects are immutable and named by content, so they can be stored without replicas agreeing on order. What is left is the small amount of mutable reference state. GitHub says a small consensus group will remain in the final design. It has promised more detail at GitHub Universe and in the final post of the series next week.
What developers and operators should take from it
GitHub has announced no Git command changes and no steps for repository owners. These points are my inferences from the described design, not GitHub guidance:
- Spread independent work across branches. Agents or jobs with their own branches should gain concurrency. A single shared branch will still queue.
- Merge queues stay contended by nature. Trunk-based flows that funnel merges into one reference are exactly the case per-reference locking can't parallelize. The October 6 post names this as a challenge GitHub is working on.
- Don't assume the newest read from every path. As virtual read replicas appear, reads that need the latest state may depend on inline reconciliation, which GitHub describes as still to come.
- Measure both cases. If you run heavy automation, test distinct-branch pushes and same-branch pushes separately. They are likely to behave very differently.
The bottom line
The takeaway is that GitHub is moving Git hosting onto Azure in stages. The busiest repositories are the last holdouts, and per-reference locking is the key that lets them move. It's a sensible change that doesn't alter Git semantics, and the 3–4x figure comes only from GitHub's own tests. The more ambitious design, and the 35x write-throughput claim from the October 6 post, arrive in the next installment.