Over the past year, as Git traffic grew exponentially, nearly all of the Git repositories on GitHub began living in two places at once: GitHub's own data centers and Azure. The busiest repositories remain constrained by a single factor: a 25ms round trip between regions.
In an earlier post, GitHub laid out two principles behind its next-generation storage architecture: minimize coordination and decouple storage from compute. This post examines the bridge between the old design and the new one. A change to the way the quorum serializes writes gets the busiest repositories into Azure, and that same step opens the door to replicas that keep no persistent state of their own.
The timing of the move was driven by the agentic shift: rapidly growing traffic, a hard ceiling on power capacity in GitHub's data centers and surrounding region, and physical supply chain constraints. The remaining capacity gave enough time to migrate safely, but not enough to do it slowly. Because Git operations are a Tier 0 service that nearly everything on GitHub depends on, the data had to move first, with the architecture evolving once it arrived. The first copy of a repository landed in Azure's Central US region in August 2025. Today, most repositories have two of their five replicas in Azure, and Azure serves about half of Git traffic.
The remaining 0.00001% of repositories present a harder problem. In the current architecture, a write waits for every healthy replica to respond, so the slowest replica sets both latency and throughput. A replica in the target Azure region sits about 1,000 miles away, and each write requires multiple round trips. The answer lies in minimizing coordination: Git's consistency requirements apply to each reference individually, and updates to different references usually do not depend on each other, so they need not be serialized.
Source: Hacker News · Summarized by HeadlinesBriefing