In a significant engineering milestone, GitHub has announced that it has successfully migrated 99.99999% of its Git repositories to Microsoft Azure. This massive undertaking, which has spanned the better part of the past year, represents a fundamental shift in how the platform manages its core storage architecture. While the majority of the platform’s data now resides in the cloud, the remaining 0.00001% of repositories—representing the busiest and most performance-sensitive projects on the site—have posed a unique challenge. To bring these repositories into the cloud, GitHub is now rolling out a new "per-reference" quorum strategy, a move that promises to solve critical latency issues while decoupling read and write operations for unprecedented scalability.
The Challenge of Growth and Geography
The impetus for this massive infrastructure transition was driven by a combination of factors: an exponential surge in Git traffic, hard physical limits on the power capacity of GitHub’s proprietary data centers, and the inevitable constraints of global supply chains. As the platform grew, the engineering team realized that expanding their existing physical footprint was no longer a sustainable strategy for the long term.
GitHub’s internal storage architecture, known as Spokes, has historically managed data through a quorum-based system. In this model, a repository is kept across multiple replicas to ensure durability and availability. When a write occurs, the system requires a majority of replicas to acknowledge the change before it is considered committed. However, as the team began migrating data to Azure, they encountered a stubborn hurdle: the speed of light.
When a repository is split between an on-premises data center and an Azure region, every write operation requires cross-region network communication. With a 25ms round trip time between these points, the latency quickly accumulates. Because GitHub’s current architecture holds a repository-wide lock during the commit process, the slowest replica in the quorum effectively dictates the performance of the entire repository. For the busiest repositories—those handling massive amounts of concurrent traffic—this bottleneck created a hard ceiling on throughput. If a repository was already operating near its limit, the added latency of the migration process would cause it to fall behind, creating a cascade of performance degradation.
Moving the Data First, Evolving Later
GitHub’s migration strategy was characterized by extreme caution. Given that Git operations are considered a "Tier 0" service—the absolute bedrock of the platform—the team could not afford to risk downtime or data integrity. Their approach was to move the data first and evolve the architecture once the transition was complete.
The first repository replica landed in Azure’s Central US region in August 2025. Since then, the migration has followed a methodical path: traffic follows the data. Through a system of preferential routing, Spokes directs traffic to replicas located in the same region and availability zone as the user, minimizing latency. As more replicas were moved to the cloud, the percentage of traffic served by Azure grew proportionally. This allowed GitHub to absorb the explosive growth in Git traffic—largely fueled by the rise of agentic development—within Azure, while their existing data centers remained steady.
Solving the Throughput Bottleneck: Per-Reference Quorums
To bring the final, busiest 0.00001% of repositories into the cloud, GitHub needed to fundamentally change how its quorum handles writes. The previous design relied on a repository-wide lock, which essentially turned the quorum into a single, unordered queue. In this configuration, if one process was pushing to a branch, no other process could write to any other branch in that same repository without waiting for the first one to finish.
The engineering team identified that Git’s consistency requirements do not actually necessitate this level of global locking. Git is inherently reference-based; as long as the server ensures that an update to a specific reference (such as a branch or a tag) is atomic and consistent, the updates to different references can happen independently.
By shifting the scope of the quorum from the repository level to the individual reference level, GitHub has effectively eliminated the single-queue bottleneck. Under this new model, writes to different branches can occur concurrently, meaning they no longer have to wait for one another to clear the 25ms cross-region network trip. Only writes that contend on the same reference are required to wait for each other. Internal testing has confirmed that this shift provides a 3-to-4x increase in write throughput while simultaneously reducing latency, providing the necessary "headroom" to move the most active repositories into the cloud without sacrificing performance.
Decoupling Reads and Writes
Beyond solving the immediate migration challenge, this architectural shift paves the way for a more robust, scalable future. Historically, read and write operations at GitHub have competed for the same resources on the same replicas. This meant that the platform could not scale its read capacity independently of its write capacity, despite the fact that most repositories are heavily "read-skewed," often seeing hundreds or even thousands of reads for every single write.
The solution involves a transition toward ephemeral compute nodes and object storage. GitHub is introducing a "virtual replica"—a compute node that does not store persistent state but instead serves as a bridge to Azure Blob Storage. This node acts as a member of the write quorum, ensuring that data is durably stored before acknowledging the transaction, but it does not participate in serving read traffic.
Once the data is committed to object storage, GitHub can spin up an unlimited number of virtual read replicas on demand. These nodes do not participate in the complex quorum process; instead, they warm their caches from Azure Blob Storage and serve traffic independently. This decoupling allows GitHub to optimize the configuration for each type of workload. For instance, read replicas can be configured with massive in-memory caches to improve performance, while the write-path remains optimized for durability and coordination.
The Road Ahead
While these advancements represent a massive leap forward, the engineering team at GitHub is quick to note that the journey is not yet over. Spokes has evolved over the years into a highly complex system that handles not just repository coordination, but also intelligent routing, load balancing, and background maintenance tasks like repository repair and rebalancing.
The current commit protocol has supported GitHub through the growth of its first billion repositories, but the team is already looking toward the next billion. The next major frontier is to further optimize write throughput by minimizing the ordering requirements of Git objects. Since Git objects are immutable and content-addressed, they do not necessarily require a complex consensus group to be stored. The challenge lies in ordering the necessary metadata as fast as possible without creating new bottlenecks elsewhere in the stack.
As agentic traffic continues to accelerate, these infrastructure changes are designed to provide the necessary flexibility to scale on the fly. The upcoming final chapter of this series, set to be presented at GitHub Universe, promises to detail the end-state of this architecture, the second-order effects of these changes—such as how garbage collection and compaction will scale in this new world—and the role that consensus groups will continue to play in the future of the platform. For now, the successful migration of the vast majority of GitHub’s data marks the end of an era for the platform’s physical infrastructure and the beginning of a cloud-native future.
