Over the past year, GitHub has achieved a monumental milestone in its infrastructure evolution: 99.99999% of the platform’s massive repository collection now resides in a dual-homed state, existing simultaneously within GitHub’s internal data centers and Microsoft Azure. This migration represents a critical shift in how the world’s leading software development platform manages the exponential growth of Git traffic driven by the modern "agentic" era—a period defined by automated coding assistants and high-frequency repository interactions.
While the vast majority of the platform’s data has successfully transitioned to this hybrid environment, the final, most active fraction of repositories has remained tied to legacy configurations. These busiest repositories face a unique performance challenge: the 25ms round-trip latency inherent in cross-regional synchronization. To overcome this hurdle, GitHub engineers are implementing a sophisticated architectural overhaul, moving from repository-wide locks to per-reference quorums. By refining how writes are serialized and decoupling read traffic from the write quorum through the use of object storage, GitHub is positioning its infrastructure to handle the next billion repositories.
The Necessity of a Strategic Migration
The decision to migrate to Azure was not merely a matter of convenience; it was a response to the physical and operational constraints of running one of the world’s largest Git services. As traffic grew rapidly, GitHub encountered a hard ceiling regarding power capacity within its existing data centers and the surrounding geographical regions. Furthermore, global supply chain constraints limited the ability to expand physical hardware footprint at the speed required to meet the demands of AI agents and increasingly automated development workflows.
GitHub’s engineering team recognized early on that attempting to fundamentally change their storage architecture while simultaneously migrating hosting platforms would be an unacceptably high-risk endeavor. Given the critical nature of Git operations—which function as a "Tier 0" service for the entire platform—the migration required a methodical, sequenced approach. The strategy was clear: move the data first to stabilize the service, then evolve the underlying architecture once the data reached its new home.
The first repository replica landed in Azure’s Central US region in August 2025. Since that time, the migration has progressed steadily, with most repositories now maintaining two of their five replicas in Azure. Today, approximately half of all Git traffic is served directly from the cloud. This migration follows a model where traffic naturally gravitates toward the data. Spokes, GitHub’s internal storage coordination service, utilizes preferential routing to ensure that read requests are directed to a replica located in the same region and availability zone as the user, minimizing latency. As replicas move to Azure, the share of traffic handled by the cloud increases until the final replica is migrated and the original data center can be decommissioned for that repository.
Solving the "Last Mile" Problem: Per-Reference Quorums
The remaining 0.00001% of repositories—those that are exceptionally busy—have presented a unique challenge. In the current architecture, a repository spread across multiple regions suffers from a reduced write throughput ceiling. This is due to the nature of the Spokes quorum, which requires a majority to commit a write but, in practice, waits for every healthy replica to respond.
When a replica resides in an Azure region, it is physically separated from the data centers by roughly 1,000 miles. This distance introduces a 25ms network round trip. Because each write involves multiple round trips and requires a repository-wide lock, the slowest healthy replica effectively dictates the latency of every write. For a busy repository already operating near its throughput limit, the addition of this latency creates a bottleneck, causing the system to fall behind with every push.
To address this, GitHub is pivoting toward a principle of "minimizing coordination" by ensuring the system only serializes what is absolutely necessary. Under the current design, holding a repository-wide lock forces writes into a single, unordered queue, where each operation must wait for the previous one to clear the network round trips. By transitioning to per-reference serialization, GitHub is changing the scope of the quorum.
Under this new model, consistency requirements are applied at the individual reference level rather than the entire repository. Since most writes to a repository—such as developers or automated agents pushing to distinct branches—do not depend on one another, they no longer need to be serialized against the entire repository. While each write still encounters the inherent cross-region latency, multiple writes to different references can now be in flight simultaneously. Internal testing has demonstrated that this change yields a 3x to 4x increase in write throughput at lower latency, effectively clearing the path for the remaining, high-traffic repositories to move to Azure.
Decoupling Reads and Writes through Virtual Replicas
The shift in quorum management is only half of the equation. Currently, read and write operations compete for the same resources on the same replicas, preventing the platform from scaling these operations independently. This is particularly problematic given that most repositories are "read-skewed," often experiencing between 100 and 1,000 reads for every single write.
GitHub is solving this by decoupling storage from compute, utilizing Azure Blob Storage as the durable source of truth. The first phase of this evolution involves the introduction of a "virtual replica." This compute node acts as a bridge to object storage, streaming incoming writes and ensuring they are durable before acknowledging them. Crucially, this node does not serve read traffic. By making object storage a member of the quorum, GitHub ensures that even as they scale read capacity, the data remains consistent and durable.
Once the virtual write replica is in place, GitHub can spawn an unlimited number of virtual read replicas on demand. These replicas warm their local caches from Azure Blob Storage and begin serving traffic without the need to participate in the quorum. This architecture allows each read replica to be configured independently—for instance, by dedicating more memory to caching—without affecting the compaction processes required for write operations. This decoupling allows GitHub to hit significantly higher read ceilings, as evidenced by internal load testing, where the infrastructure was able to outpace the limits of the testing harness itself.
The Path Toward Future Scalability
While these advancements represent a significant leap forward, the engineering team at GitHub remains focused on the next horizon. The current Spokes service has evolved over the years into a complex system that handles intelligent routing, load balancing, a unified API for over 100 billion daily operations, and various "sweeper" systems responsible for repository repair and rebalancing.
However, the team acknowledges that the commit protocol that supported the growth of the first billion repositories will eventually need to be reimagined. The current write throughput is limited by the fact that every write still waits on replicas holding full copies of the repository. Because Git objects are immutable and named by their contents, there is an opportunity to store data without requiring universal consensus for every single operation.
Designing a system that can handle the nuance of ordering only the necessary data, without introducing new bottlenecks, is the central challenge for the next phase of development. This requires rethinking second-order effects, such as where durable reference state lives and how garbage collection scales across a billion repositories. As agentic traffic continues to climb, these incremental improvements provide the necessary headroom to ensure that GitHub remains a stable, high-performance platform for developers worldwide. The final stage of this architectural journey, and the implications for the future of repository throughput, is expected to be detailed during the upcoming GitHub Universe event.
