The bridge to agent-scale Git infrastructure
The Bridge to Agent-Scale Git Infrastructure
By Eleanor White & Victoria Dye | October 21, 2026
Over the last year, GitHub has faced a surge in Git traffic driven by the "agentic shift." To keep up, we have successfully migrated 99.99999% of our repositories to Azure. However, the final fraction of repositories—the most active ones on the platform—remain held back by a single physical constraint: a network round trip.
The Strategic Path Forward
Our transition to a next-generation storage architecture is guided by two fundamental pillars:
- Minimize coordination
- Decouple storage from compute
This article explores the "bridge" phase: how we are evolving our quorum serialization to move the busiest repositories into Azure and paving the way for stateless read replicas.
Why the Migration?
The move wasn't just a preference; it was a necessity. We hit a "hard ceiling" caused by:
- Exponential Traffic: The rise of AI agents increasing Git operations.
- Infrastructure Limits: Power capacity constraints in our own data centers and the surrounding region.
- Logistics: Physical supply chain bottlenecks.
Because Git operations are a Tier 0 service (the foundation upon which almost every other GitHub feature is built), we couldn't risk changing the architecture and the hosting platform simultaneously. Our sequence was simple: Evolve architecture Move data first, then evolve the architecture.
The Migration Process
Since August 2025, we've been shifting data to Azure's Central US region. Most repositories utilize five replicas to ensure durability and availability. We use a system called Spokes to route traffic to the closest available replica.
The Migration Checklist:
- Establish Azure Central US footprint.
- Move 2 of 5 replicas for the majority of repos.
- Shift of Git traffic to Azure.
- Migrate the final of high-traffic repositories.
Solving the "Last Mile" Problem
Why are the busiest repositories the hardest to move? The answer lies in how our current quorum handles writes.
The Bottleneck: Repository-Wide Locking
In the existing Spokes architecture, a write requires a majority of replicas to commit. While it doesn't need all of them, it waits for every healthy replica (up to a timeout) to avoid replicas falling too far behind.
This creates a performance ceiling: the slowest healthy replica determines the latency of the write.
When a repository is split between our data centers and Azure (roughly 1,000 miles apart), we introduce a round-trip delay. Because each write holds a repository-wide lock, the throughput is limited by the formula:
For a high-traffic repo, this serialized queue grows rapidly, causing subsequent writes to wait longer and longer.
The Solution: Per-Reference Quorums
We realized that Git's consistency requirements are actually more granular. Consistency is required per reference (e.g., a specific branch or tag), not for the entire repository.
By shifting the lock from the entire repository to individual references, we can allow multiple writes to happen simultaneously as long as they touch different refs.
Comparison of Serialization Models
| Feature | Repository-Wide (Old) | Per-Reference (New) |
|---|---|---|
| Lock Scope | Entire Repository | Individual ref (e.g., refs/heads/main) |
| Concurrency | Single write in flight | Multiple writes (if refs differ) |
| Latency Impact | Slowest replica slows everything | Slowest replica slows only that ref |
| Throughput | Low ceiling for cross-region | High ceiling; scales with ref count |
In real-world testing, this change resulted in 3–4x higher throughput and significantly lower latency for writes to different references—which is the common case when developers and agents push to separate branches.
Scaling Reads Independently
The final piece of the puzzle is addressing the read/write imbalance. Most repositories are heavily read-skewed, often seeing a ratio of:
1 write : 100-1,000 reads
Currently, reads and writes share the same replicas, meaning they compete for the same CPU and I/O resources. By implementing the per-reference quorum, we are opening the door to a new phase where we can decouple these operations.
The goal is to move toward replicas that maintain no persistent state of their own, allowing us to scale read capacity horizontally and independently of our write quorums.
