TL;DR
Get the latest gadgets delivered free with Prime
- Fast, free delivery on millions of items
- Prime Video, Amazon Music and more included
- Member-only deals all year
GitHub has described a new Git storage architecture, Project Rubicon, designed to support thousands of writes per second to a single repository while scaling reads separately. In internal testing, the company says it supported 5,000 concurrent agents and 7,200 pushes per second; those figures are test results, not evidence that every repository currently operates at that scale.
GitHub has outlined Project Rubicon, a new Git storage architecture designed to handle thousands of writes per second to a single repository as developers increasingly use agents to work in parallel. The company says internal testing supported 5,000 concurrent agents on a repository sending 7,200 pushes per second, while the system served read traffic with consistently low latency.
GitHub says the architecture is being built underneath the existing service while it continues running. For developers, the company says, the everyday Git workflow remains unchanged: users can push, fetch and create branches with the same protections in place. The design changes how the service stores and serves repository data, rather than requiring a new client workflow.
The central design choice is to separate Git’s immutable objects from its references. Objects are named by their contents, so GitHub says multiple writers can store them without coordinating with one another. Updating a reference—which points to a commit or other object—is the part of a push that requires agreement. The system therefore limits coordination to reference updates, while allowing storage, request serving and repository maintenance to scale more independently.
GitHub describes the system’s existing Spokes layer as continuing to route and balance requests and provide an internal API for reading and writing repository data. The underlying data plane is new. The company says its requirements include multiple writer nodes, low commit latency, and allowing a replica that has fallen behind to download only the data needed to serve a request. GitHub has not supplied in this source material a public deployment schedule or independent verification of the test results.
Preparing Repositories for Agent Work
The change targets a growing operational challenge: many agents and automated services can generate activity on one repository at the same time. GitHub says its busiest repositories currently receive at most dozens of writes in a second, usually in short bursts, but expects agent use to turn such bursts into sustained traffic. That forecast is the company’s rationale for building for substantially higher write rates.
A push can also trigger more work. Continuous integration systems may run, deployment services may fetch the new commit, and other agents may retrieve it for context. This creates read traffic that grows alongside writes, according to GitHub. Separating the components is intended to let the service add capacity where demand appears rather than scaling every part of repository infrastructure together.
The performance claims matter to teams that rely on GitHub for busy codebases, especially where automated work depends on quick pushes and subsequent reads. However, the stated figures describe internal testing; they do not establish that all customers will see those rates or that every workload will have the same latency. GitHub’s account does not provide test methodology or customer-level performance comparisons.
Popular right now
Shark IQ Robot Self-Empty XL Robot Vacuum with Home Mapping, Self-Cleaning Brushroll, and Wi-Fi, Black
KitchenAid Artisan 5-Qt Tilt-Head Stand Mixer – Almond Cream (KSM150PS)
KitchenAid 5.5-Qt Bowl-Lift Stand Mixer, Porcelain White (KSM55SXXX)
As an affiliate, we earn on qualifying purchases.
From Azure Migration to Rubicon
Rubicon follows an earlier storage change described in the same GitHub engineering series. GitHub says it moved 99.99999% of repositories into Azure, narrowed the write quorum to individual references and created virtual replicas backed by Azure Blob Storage. The company presents those replicas as the first step in onboarding repositories to the new architecture.
GitHub says it began working on the Rubicon design in May 2026, after the initial Azure migration. It evaluated multiple approaches, all of which stored pack data in Azure Blob Storage; some also tried storing reference state there. The company says it selected the design it believed best balanced throughput with correctness, durability, availability and latency. Those are GitHub’s descriptions of its design goals, not independently assessed results.
The architecture responds to both horizontal and vertical scale. Horizontal scale concerns activity spread across many repositories, for which GitHub says it will retain established approaches such as tenant partitioning, traffic isolation and load-aware routing. Vertical scale concerns a single repository becoming much busier. GitHub says the latter drove most of the new system’s requirements as agents began changing the expected pattern of repository use.
““Only reference updates need agreement.””
— GitHub
Testing Results and Rollout Details
The published account does not say when Rubicon will be generally available, how many repositories currently use it, or whether the test configuration represents typical customer workloads. GitHub reports the 5,000-agent and 7,200-push-per-second results as internal testing, but the material provided does not include detailed test conditions, duration, hardware configuration or an independent assessment.
It is also not yet clear how quickly the company expects agent-driven activity to reach its forecast of sustained write rates, or what performance customers should expect across repositories of different sizes. GitHub says it is building the system while the service remains operational, but does not give migration milestones or describe any customer-facing changes beyond the assurance that Git workflows and protections stay the same.
Further Details on the Data Plane
GitHub says its engineering series will explain how requests move through Rubicon and examine two of the architecture’s components. Those details should clarify how the new data plane handles writes and reads, and how it meets the stated requirements for latency, durability and availability.
The next practical milestone will be clearer information about deployment: which repositories are being moved, on what schedule, and whether GitHub will publish additional measurements as the system operates at customer scale. Until then, the disclosed throughput figures should be understood as internal test results, while the architecture’s broader rollout and real-world performance remain unreported.
Key Questions
What is Project Rubicon?
Project Rubicon is GitHub’s name for a new Git storage architecture intended to handle higher write rates on individual repositories and allow parts of the storage system to scale independently.
What performance did GitHub report?
GitHub says internal testing supported 5,000 concurrent agents working on one repository and sending 7,200 pushes per second, while the system served read traffic with consistently low latency. The post does not provide detailed test conditions.
Will developers need to change how they use Git?
GitHub says developers will continue to push, fetch and branch as before, with the same protections. The change is to the service’s storage architecture, not the described client workflow.
When will the new architecture be available?
GitHub has not provided a public rollout schedule in the source material. It says the system is being built underneath the running service, but does not specify how many repositories have moved or when deployment will be complete.
Source: github.blog
