GitHub demoed a new Git storage backend that handles 7,200 pushes per second on a single repository. The system covers all GitHub.com repositories and requires no attacker access, it is a performance redesign for agentic writes.
Before that, the busiest repositories on GitHub.com received at most dozens of writes in a single second in short bursts.
Now GitHub says internal testing supports 5,000 concurrent agents on one repository with consistently low read latency.
The shift accelerated over the past year as agents changed write patterns. One repository cited by GitHub grew about 4x in daily requests from March to May and kept growing on an exponential trajectory, which pushed the team to target two orders of magnitude more vertical scale for a single repository.
The foundation was a bridge step described in the series. GitHub moved 99.99999% of repositories into Azure, scoped the write quorum to individual references, and stood up virtual replicas backed by Azure Blob Storage. Those replicas are disposable compute with local disk as cache, and they onboard repositories to the new architecture.
Project Rubicon followed. GitHub started the design in May of 2026 and announced it last week at GitHub Universe, then detailed it in a post by Karthik Raman and Brian Celenza. The team tried several approaches with pack data in Blob Storage and some with reference state there, then settled on Rubicon to maximize throughput while keeping correctness and durability.
Rubicon builds on one observation. Git objects are immutable and content-addressed, so writers can store them without agreement. Only the reference update needs coordination, and that update is tiny. The architecture decouples storing data, serving requests, and maintaining repositories so each scales independently. Requests from Git clients, the API and the web UI still hit Spokes for routing, placement and tenant fairness, then Spokes routes to a small group of virtual replicas assigned to the repository where caches stay warm.
Requirements were explicit. Accept thousands of writes per second. Support multiple writer nodes to spread CPU-heavy pack indexing and connectivity checks and to improve fault tolerance. Minimize commit latency for agents. Keep an ordered record per reference, allow quick linearization across references, and keep reads cheap when nothing has changed.
What still has to happen is sustained load. GitHub said it expects bursts to become a sustained rate within the next year as agents run in parallel around the clock, testing whether reads that scale on demand and writes that fan out to CI and other agents hold under continuous pressure.
