GitHub moved 99.99999% of repositories to Azure and will scale Git reads via object storage

GitHub has revealed that 99.99999% of the Git repositories on its platform now exist in both its own data centers and Azure, and has laid out the engineering work needed to move the final, busiest holdouts and then scale reads independently through object storage. In an engineering post on the GitHub Blog, the company said the timing was set by rapidly growing traffic from agentic workloads, a hard ceiling on the power available to its data centers and the surrounding region, and supply chain constraints.

The migration so far

According to the GitHub Blog, the first repository copy arrived in Azure's Central US region in August 2025. Since then the migration has progressed replica by replica: most repositories keep five replicas to balance durability, availability and scale, and two of the five now typically sit in Azure. The company says Azure handles roughly half of all Git traffic today, and that for most of the migration the cloud absorbed platform growth while load on its own data centers stayed steady.

GitHub's replication system, Spokes, routes requests preferentially to a replica in the same region and availability zone as the caller. Every replica that lands in Azure allows a larger share of that repository's requests to be answered there, and once the final replica arrives, the legacy region stops taking its traffic. Because Git operations are a Tier 0 service that nearly everything else at GitHub depends on, the company sequenced the work deliberately: relocate the data and its dependencies first, evolve the storage architecture afterwards.

Why the last repositories are stuck

The remaining 0.00001% of repositories are among the busiest on the platform, and the obstacle is network distance: the target Azure region sits roughly 1,000 miles from GitHub's data centers, adding about 25ms per round trip, and a single write requires several round trips.

The deeper problem, as GitHub explains it, is how the write quorum serializes. Spokes needs only a majority of replicas to commit a write, but it still waits for every healthy replica to respond before moving on. The slowest replica therefore dictates the latency of every write, and since each write holds a lock across the whole repository until it commits, it also sets the repository's throughput ceiling. A repository already running near that ceiling cannot absorb an extra 25ms on every serialized write without falling further behind on each push.

Shrinking the quorum to a single reference

GitHub's answer is to narrow the quorum's scope from the entire repository to individual references — branches and tags. Git's consistency guarantee applies to each reference on its own: once the server accepts an update, clients should only ever see that value or a newer one. Updates to different references are usually independent and can proceed without waiting on each other.

Under per-reference serialization, only writes contending for the same reference queue up. Writes to different branches — for example, agents and developers each pushing their own — can be in flight at the same time, even though each still pays the cross-region latency. In internal testing with realistic traffic, GitHub measured roughly 3–4x higher throughput at lower latency for writes hitting distinct references, and says a repository's write ceiling rises roughly in proportion to the number of references written at once.

Object storage as a virtual replica

The same change underpins the second phase: decoupling reads from writes. Repositories are heavily skewed toward reads — GitHub puts it at between 100 and 1,000 reads per write — but reads and writes currently hit the same replicas and compete for the same resources, so neither can be scaled separately.

The first step makes Azure Blob Storage a member of the write quorum as a "virtual replica," represented by GitHub's first fully ephemeral node. It accepts a stream of incoming writes but serves no read traffic, and because it belongs to the quorum, a write is not acknowledged until it is durable in object storage. The node also batches writes to unrelated references together, so a busy repository pays one round trip to object storage across many concurrent writes instead of one per write. For now it also handles compaction, with read replicas inheriting the compacted state.

On top of that, GitHub can spin up virtual read replicas on demand. Each loads its cache from object storage, starts serving reads without joining the quorum, and syncs its local state with object storage in the background. In internal load testing, the distributed harness that routinely exposed ceilings in the current architecture ran out of headroom itself before the virtual read replicas did.

Why it matters

GitHub describes the move as forced by circumstance: agentic traffic growth, a power ceiling on its facilities and supply chain limits left no room for a slow migration of a Tier 0 service. The redesign also anticipates a different traffic profile, with agents and developers pushing to many separate references at once — a pattern per-reference quorums handle directly — while object-backed read replicas let read capacity grow independently of the write quorum. For users, the practical stakes are higher throughput ceilings on busy repositories and reads that no longer compete with writes; for the wider industry, it is a concrete case of AI-driven workloads reshaping core infrastructure design.