Why move now, and why in a hurry
In an October 21 post on its engineering blog, GitHub put the reason for migrating its Git storage squarely on "the agentic shift": Git traffic has grown exponentially over the past year, power capacity at its own data centers and the surrounding region has hit a hard ceiling, and the hardware supply chain is constrained. In GitHub's words, the capacity it had left when the migration started was enough time to move safely, but not enough to move slowly.
Where it stands: the first repository copy landed in Azure's Central US region in August 2025. Today 99.99999% of repositories live in both GitHub's own data centers and Azure, most repositories have 2 of their 5 replicas in Azure, and Azure serves about half of Git traffic, absorbing most of the growth over that period. Repository owners don't need to do anything.
Where the last 0.00001% is stuck
The repositories that haven't moved are exactly the busiest on the platform. GitHub's storage layer, Spokes, commits writes by majority quorum, but it waits for every healthy replica to respond (up to a timeout), and each write holds a repository-wide lock until it commits. So the slowest replica sets both the latency of every write and the repository's throughput ceiling. The Azure region is about 1,000 miles from the original data centers, a round trip takes about 25 ms and a write needs several of them. For a repository already near its ceiling, that added latency just makes the queue of pushes grow longer.
The fix is to narrow what gets serialized. Git's consistency rules only require that a single reference (a branch or tag) never goes backwards; updates to different references are mostly independent. GitHub is changing the quorum from whole-repository to per-reference, so only writes to the same reference have to wait for each other. Agents and developers pushing to their own branches is the norm, and in internal testing with realistic traffic, writes to different references consistently got 3–4x higher throughput at lower latency.
Scaling reads and writes separately
The other half of the work targets reads. Most repositories see 100 to 1,000 reads for every write, but today reads and writes share the same replicas. GitHub is making Azure Blob Storage a "virtual write replica" in the quorum, so a write isn't acknowledged until it is durable in object storage. On top of that it can spin up as many "virtual read replicas" as needed, which warm their caches from object storage and start serving reads without joining the quorum. In internal load tests, the load-testing harness hit its own limits first.
GitHub also admits that the ceiling on write throughput is still the quorum itself; the end-state design will be shown at GitHub Universe on October 28–29 and in the final post of the series. For users, these numbers say something more memorable than the migration itself: agents don't just add more users, they pushed a hosting platform's write model and its data center power to the limit at the same time.
via: GitHub Blog: The bridge to agent-scale Git infrastructure