GitHub's bridge to agent-scale Git infrastructure: per-reference quorum and virtual replicas

GitHub explains on its engineering blog how it is rebuilding its Git infrastructure, while the service keeps running, to handle growing traffic generated by AI agents. The article, written by two GitHub engineers, describes the bridge between the current design and the next-generation storage architecture. It is part of a series that follows up on an earlier post, with a final installment announced for the following week, coinciding with GitHub Universe.

According to the post, 99.99999% of Git repositories on GitHub already live in two places at once: the company's own data centers and Azure. The timing and shape of the migration were driven by three factors: rapid traffic growth from the shift toward agentic workloads, a hard ceiling on electrical capacity in the data centers and their geographic region, and physical supply-chain constraints. The remaining capacity left enough time to migrate safely, but not to do it slowly. That is why GitHub decided to change where the data lives first and evolve the architecture afterward. Changing both the storage architecture and the hosting platform at the same time, amid that growth, carried too much risk.

Git operations are a Tier 0 service: almost everything on GitHub depends on repository data, so data, services and dependencies had to move first. The first copy of a repository reached Azure's Central US region in August 2025. Today, most repositories have two of their five replicas in Azure, and Azure serves roughly half of Git traffic. During the migration, traffic follows the data: Spokes, GitHub's storage system, uses preferential routing to a replica in the same region and availability zone as the request. Each replica that lands in Azure increases the share of traffic that can be served from there, until the last replica arrives and the old region stops receiving requests.

Left out of that migration are 0.00001% of repositories, which are among the most active on the platform. The obstacle is a round-trip latency of about 25 ms. In the current architecture, a repository hosted across multiple regions has a lower write throughput ceiling. Spokes' quorum only needs a majority to commit a write, but it waits for a response from all healthy replicas (up to a timeout). As a result, the slowest healthy replica sets the latency of every write. Because each write holds a repository-level lock until it is committed, it also sets the throughput ceiling. A replica in the target Azure region sits about 1,000 miles from the data centers, and a write requires several round trips. A repository near its ceiling cannot absorb that on every serialized write and would fall further behind with each push.

This is where the first principle comes in, minimizing coordination: don't serialize what doesn't need to be serialized. Git's consistency requirements apply to each ref individually. Once the server accepts an update to a ref, no client should later see an older value, whether through a fast-forward, a force push or a deletion. But updates to different refs are usually independent. GitHub is therefore changing the scope of the quorum from the entire repository to each individual ref. With per-ref serialization, only writes competing for the same ref wait on one another. In practice, agents and developers usually push to their own branches, so they no longer block each other. Each write still incurs cross-region latency, but several can be in flight at once. The write ceiling rises roughly in proportion to the number of refs being written simultaneously. In internal tests with realistic traffic, writes to different refs consistently achieved 3 to 4 times more throughput with lower latency.

The second part deals with scaling reads separately. Most repositories are heavily read-skewed, with between 100 and 1,000 reads for every write. Today, reads and writes hit the same replicas, compete for the same resources and cannot be scaled independently. By decoupling storage and compute, repository data is stored durably in Azure Blob Storage and updated with every write. This makes it possible to separate read traffic from the write quorum and scale the compute for each. Reads, for example, would benefit from far more in-memory caching than they get today, but that memory is also needed for compaction.

The first step is to make object storage a member of the quorum, as a special type called a virtual replica. The compute that represents it is the first fully ephemeral node: it acts as a bridge to object storage, streams incoming writes and does not serve reads. Because it is a quorum member, a write is not committed until it is durable in object storage. That adds some latency, but per-ref serialization keeps it from becoming a throughput bottleneck. In addition, this virtual write replica batches transactions on disjoint refs into a single set of network operations to storage, so a busy repository pays a single round trip for many concurrent writes. For now it also handles compaction, and read replicas inherit the compacted state.

With it in place, as many virtual read replicas as a repository needs can be spun up on demand. Each one warms its cache from Azure Blob Storage and starts receiving read traffic without joining the quorum. It uses object storage as the source of truth and reconciles its local state in the background. GitHub says that in internal tests its distributed load-testing harness routinely hit ceilings in the current architecture, whereas against the virtual read replicas the harness reached its own limits first.

The approach has limitations, which the article says will be addressed in later steps. Because reconciliation happens in the background, these replicas suit some read workloads but not all. Serving any kind of read requires reconciling inline, fetching only the ref state and data that have changed since the replica was last brought up to date. Moreover, although the per-ref model raises write throughput, the quorum remains the limiting factor.

Looking ahead, the authors note that Spokes is now much more than a quorum coordinator. It is also an intelligent routing and load-balancing layer, a unified API that internal clients use to access repository data with well over 100 billion operations a day, and a set of background systems called “sweepers” that handle placement, repair and rebalancing. Nearly all of that carries over unchanged to the new architecture. However, GitHub acknowledges that the commit protocol that took it to one billion repositories will not take it to the next billion.

The next limit is write throughput. Every write still waits on replicas that hold a full copy of the repository, even though very little of a write actually needs to be ordered. Git objects are immutable and content-addressed, so they can be stored without consensus. What remains is small, and the hard part is ordering it as fast as possible without shifting the bottleneck elsewhere. Doing so means rethinking second-order effects, such as where durable ref state lives and how compaction and garbage collection scale. The final installment of the series, announced for GitHub Universe, will describe that end state, its effect on write throughput, the second-order problems solved and why a small consensus group will still exist somewhere in the stack.

Overall, the article is a GitHub engineering deep dive into a migration to Azure shaped by agent traffic. The performance figures cited (3 to 4 times more throughput on writes to different refs) come from the company's own internal tests and have not been independently verified.