GitHub details new storage backend, claiming 7,200 pushes per second in internal tests

Thousands of coding agents can work on one repository without overwhelming its storage backend, according to GitHub’s internal tests of Project Rubicon. In a November 5 engineering disclosure, GitHub said its redesigned architecture supported 5,000 concurrent agents and 7,200 pushes per second to one repository, while keeping read latency consistently low.

The disclosure follows GitHub’s announcement of the architecture at GitHub Universe the previous week. It explains how the company is rebuilding the infrastructure beneath familiar Git workflows, rather than requiring developers to change how they push, fetch or create branches.

Short bursts versus sustained machine traffic

GitHub says its busiest repositories currently receive at most dozens of writes in a second, usually in brief bursts. It expects agents working in parallel and around the clock to turn those bursts into sustained traffic within the next year. Rubicon’s design target was at least two orders of magnitude more single-repository scale—not a measured improvement of that size.

Writes are only the beginning of the load. Each push prompts more downloads as automated checks run, deployment systems pull new code and other agents fetch it for context. GitHub says reads outnumber writes by orders of magnitude, making a design that accelerates uploads at readers’ expense a poor fit.

Why storing everything together fell short

The key distinction is between code data and references—the changeable pointers identifying code revisions. Git objects never change after creation and are identified by their contents, so writers can store them simultaneously without agreeing on an order. References need coordination because multiple writers may try to change the same pointer.

GitHub initially tried keeping reference state in Azure Blob Storage alongside the code data. Two prototypes exposed a tradeoff: keeping updates together constrained writes, while splitting them apart made reads more expensive.

Rubicon instead puts references in a dedicated replicated log service called Ref-CAS. Each transaction locks only the references it touches, checks that their values match the writer’s expectations, and becomes visible after a majority of log replicas record it. GitHub says reference transactions alone reach tens of thousands of operations per second.

That does not eliminate conflicts. GitHub says agents mostly push to their own branches, allowing unrelated updates to proceed in parallel. When two pushes try to change the same reference from the same expected value, only one can succeed.

Serving requests without owning the durable copy

The machines serving requests are disposable virtual replicas. Their local disks hold rebuildable caches, not the durable repository. Git objects live in Azure Blob Storage; references and the manifest listing the repository’s stored bundles live in Ref-CAS. The request paths reflect that split:

1. Writing: A virtual replica indexes an incoming pack—a bundle of Git objects—and uploads it to Blob Storage. It then commits one Ref-CAS transaction listing the pack and updating references. The pointer changes only after the underlying objects are durably stored.
2. Reading: A virtual replica checks its reference version with Ref-CAS and downloads the packs it needs into its cache. If its version is already current, the reference check returns no references, avoiding an unnecessary transfer.

Maintenance moves off those request-serving machines, too. Every push adds a pack, and accumulating packs makes lookups more expensive. Separate compaction nodes merge packs and remove unreachable objects directly against durable storage. Unlike the legacy architecture, that work does not compete for CPU and memory on replicas serving live traffic.