GitHub is changing how it locks Git writes so its busiest repositories can finally move to Azure, and the same change sets up replicas that store nothing themselves.
The company said 99.99999% of its repositories now live in two places, its own data centers and Azure. The first copy landed in Azure's Central US region in August 2025. Most repositories now keep two of their five replicas there, and Azure serves about half of Git traffic. The holdouts are the busiest repositories, and what holds them back is a 25ms round trip. The Azure region sits about 1,000 miles from GitHub's data centers, and a single write needs several round trips.
The cause is the quorum, the group of replicas that must agree on each write. It needs only a majority to commit, but it waits for every healthy replica, so the slowest one sets latency. Each write also holds a repository-wide lock, so that same replica caps throughput. GitHub is narrowing the lock to individual references, such as branches. Git's consistency rules apply per reference anyway, so writes to different branches no longer queue behind each other. In internal testing, the company said, those writes saw 3x to 4x higher throughput at lower latency.
The second half is reads, which outnumber writes by 100 to 1,000 times in most repositories. Object storage becomes a quorum member called a virtual replica, a fully ephemeral node that streams writes and serves no reads. Read replicas can then spin up on demand, warm their caches from Azure Blob Storage, and stay out of the quorum. GitHub said its load-testing harness hit its own limits before the new replicas did.
The sequencing is the more interesting choice. GitHub framed the move as driven by agent traffic, a hard power ceiling in its data centers, and supply chain limits, and decided against changing hosting and architecture at once. These figures are the company's own tests, and the read replicas do not yet suit every workload. Serving all reads needs reconciliation moved in-line, which GitHub left to later steps. The open question is how well per-reference locking holds up when many agents push to the same branch.