GitHub has announced a new Git storage architecture designed to handle thousands of writes per second to a single repository while scaling reads as demand grows. In internal tests, the company says it supported 5,000 concurrent agents and 7,200 pushes per second to one repository while keeping read latency consistently low.
The design, called Rubicon, separates the work of storing Git data, serving requests and maintaining repositories. GitHub says developers can keep pushing, fetching and branching in the same way, with the same protections in place.
Data lives in Azure Blob Storage
Most durable data in the new system lives in Azure Blob Storage. Branch updates and other Git reference changes go through a separate service called Ref-CAS. GitHub says this limits coordination to the small part of a push where writers need to agree on what changed. A push’s data is stored before its reference update is committed.
Requests run through virtual replicas whose local disks act as caches. GitHub says it can add replicas when a repository gets busy. If one goes away, other replicas can keep serving requests while its replacement builds a cache.
GitHub has also moved pack compaction to separate background nodes. They combine packs created by pushes into fewer, larger packs, so maintenance work does not run on the replicas serving traffic. The company says its tests have shown consistently stable latency as writes increase.
GitHub has not announced a rollout date
GitHub says it began designing Rubicon in May 2026 and is building it underneath its running service. Virtual replicas are part of how it brings repositories onto the new architecture, but the company has not given a date for a full rollout. Its next areas of work are scaling the system further, making agents more efficient on GitHub and adapting Git for agent-driven development.
