GitHub has moved copies of 99.99999% of its repositories to Azure, while keeping copies in its own data centers. The remaining repositories are among the platform’s busiest, and cross-region network latency has made their migration difficult. The company says changing how it coordinates writes will help bring them over and support a shift toward infrastructure designed for growing traffic from developers and AI agents.
The migration began with a copy of a repository arriving in Azure’s Central US region in August 2025. Most repositories now have two of their five replicas in Azure, which serves about half of Git traffic. GitHub chose to move data before changing its storage architecture, citing the importance of Git operations and the risks of changing both the hosting platform and architecture at the same time.
In the current design, a write quorum waits for every healthy replica to respond, even though a majority is enough to commit a write. Because a repository-wide lock remains in place until the write completes, the slowest replica can limit both latency and throughput. With Azure replicas about 1,000 miles from GitHub’s data centers, a network round trip takes around 25 milliseconds, and writes require multiple trips.
GitHub’s proposed change is to coordinate writes per reference rather than across an entire repository. References include branch pointers, and the company says updates to different references usually do not depend on one another. Under the new approach, writes to the same reference still wait for each other, while writes to separate references can proceed concurrently. In internal tests using realistic traffic, GitHub reports 3–4 times higher throughput for writes to different references, with lower latency.
The change also supports a separate scaling path for reads. GitHub says repositories typically receive between 100 and 1,000 reads for every write, but currently both kinds of traffic use the same replicas and compete for resources. Its next step is to make Azure Blob Storage part of the write quorum through a “virtual replica.” This ephemeral node streams incoming writes to object storage, and a write is acknowledged only after it is durable there.
The virtual write replica does not serve reads. Instead, GitHub can create virtual read replicas on demand, warming their caches from Blob Storage and serving read traffic without joining the quorum. In internal load tests, GitHub says its testing system reached its own limits before finding a ceiling for these replicas. The company notes that background reconciliation may not suit every read workload, and that further improvements are needed to raise write throughput beyond the limits of the quorum.
GitHub says the next challenge is ordering the small amount of repository data that needs coordination, while storing immutable Git objects without requiring agreement between replicas. The company plans to describe its intended end-state architecture in a forthcoming post and at GitHub Universe. тә
Sources: GitHub Blog.