GitHub rebuilds its Git storage to handle writes at agent scale

GitHub is moving the world's Git repositories out of its own data centers and into Azure, and a new engineering post explains the hard part that remains. The copy itself is nearly done: about 99.99999% of repositories now live in Azure, most with two of five replicas there, and Azure already serves roughly half of all Git traffic. The problem is the busiest repositories. Every write has to wait for replicas about 25 milliseconds away, and that round trip is what keeps the heaviest repos from moving cleanly.

The fix is to stop treating a repository as one unit for write coordination. GitHub now runs a separate quorum per Git reference, so a push to one branch no longer waits on a push to another. In tests that raised write throughput by three to four times at lower latency. Underneath, repository data sits durably in Azure Blob Storage, and an ephemeral "virtual write replica" streams writes to that storage, batching concurrent writes into shared round trips and acknowledging them only once they are durable. Read replicas warm their caches from the same object storage and serve reads without joining the quorum, which separates read scaling from write coordination. Read-heavy repos see 100 to 1,000 reads per write, so that split matters.

The scale numbers give a sense of the load. Spokes, the routing and quorum layer, handles well over 100 billion operations a day. GitHub says a follow-up post will describe the end state, and that a small consensus group stays in the stack.

Why it matters

If you run large repositories or point swarms of coding agents at them, write latency is the wall you hit first, and GitHub is rebuilding its storage layer specifically around that. The per-reference design is also a hint about how code hosts plan to handle many agents writing to the same repo at once, which is worth watching if you are designing agent-heavy workflows.