---
type: analysis
slug: research-github-is-moving-git-storage-off-its-five-replica-spokes-design-onto-azure-blob
title: "GitHub is moving Git storage off its five-replica Spokes design onto Azure Blob Storage, but its 35x speedup claim is an internal benchmark"
description: "GitHub says agent-driven pushes grew nearly 5x in a year and exposed the write-path limits of Spokes. Its fix is to separate durability from serving and to coordinate only ref updates. The measured evidence so far is one internal benchmark result."
published_at: 2026-10-22T08:00:00.000Z
topics: ["github","design","agents","research"]
source_urls: ["https://github.blog/engineering/architecture-optimization/building-git-infrastructure-for-agent-scale-development","https://github.blog/engineering/infrastructure/stretching-spokes/","https://www.theregister.com/devops/2026/10/09/so-long-spokes-github-rewrites-storage-to-restore-reliability-just-in-time-for-agentic-hordes/5302148","https://github.blog/news-insights/company-news/github-availability-report-may-2026/"]
author: "Andrey Reshetnikov"
author_profile: https://newruntime.com/owner-profile.md
---
On October 6, 2026, Brian Celenza, a principal engineer on GitHub's storage and core services team, published "Building Git infrastructure for agent-scale development." The post says agentic workflows have produced write-heavy, highly concurrent load that GitHub's Git backend was not designed for. Agents commit or checkpoint after nearly every action. Thousands of agent branches put pressure on a single repository. Merge queues converge on one ref, and CI fetches the same branch tip thousands of times a minute. GitHub says it is rebuilding the storage layer while the service stays live. A follow-up post is promised to cover the target architecture in more detail.

This matters to anyone running coding agents against GitHub. Push latency and write availability on hot repositories set the pace of an agent loop. GitHub had a rough reliability stretch in 2026, with 10 incidents in April and nine in May according to its own reports. The rewrite is GitHub's structural answer to that load, but most of it is described as a plan, not as something already shipped.

## What we checked

- **What specific Git infrastructure changes does GitHub describe, and what evidence does it provide that they address agent-scale development workloads?** partly confirmed. GitHub names two concrete changes. First, it narrows coordination so that only the ref update needs quorum, while object storage, connectivity checks and secret scanning run in parallel and compaction and garbage collection move to separate workers. Second, it separates storage from compute: authoritative data goes to Azure Blob Storage and elastic caching workers serve requests. The supporting evidence is platform-wide growth metrics plus an internal benchmark of 'up to 35 times higher write throughput.' The post describes neither the benchmark's method nor any agent-specific test, and gives no rollout timeline. [1][3]
- **Is the rebuild connected to GitHub's 2026 reliability problems and its Azure migration?** partly confirmed. GitHub's May 2026 availability report blames rapid traffic growth on 'AI-assisted and agentic development workflows' and lists nine incidents. It also says 30% of Git traffic runs on Azure and repository replication is at 99%. The Register links the rewrite to those incidents. The engineering post itself mentions no outages and does not describe an Azure migration. [4][3]

## What we found

- The bottleneck is Spokes, GitHub's own replication design. It keeps every repository as a full copy on local disks of several fileservers, five by default, and uses three-phase commit with quorum for ref updates. In the post's words, 'Every replica participates in every write, so a push is only as fast as the slowest replica in its set,' and 'losing quorum stops writes entirely.' Adding read capacity means adding durable replicas, which slows writes. GitHub's 2017 Spokes post already noted that three-phase commit costs four round-trips to distant replicas. [1][2]
- Change one is to coordinate only what needs agreement. Under the new design only the reference update requires consensus. Object storage, connectivity validation and secret scanning can run in parallel with other writes, which shortens the critical path to acknowledging a push. Compaction and garbage collection move off the hosts that serve live traffic to separate workers operating on durable storage. [1]
- Change two separates storage from compute. Authoritative repository data lives in Azure Blob Storage, and lightweight workers cache data and serve Git requests. Losing a worker is treated as a cache miss: a replacement can start serving immediately and warm its cache from durable storage. Workers can be added for bursts such as releases or new agent fleets. GitHub says branch protections, required reviews, audit logs and visibility rules carry over. [1]
- GitHub's case rests on growth figures. Git events rose from 218.2B to 473.3B per month between September 2025 and August 2026. September commits reached 7.38B, more than 5x a year earlier. Monthly pushes went from 0.69B to 3.35B, about 4.9x. PR merges grew nearly 4x, Actions runs reached 3.26B in September, and the busiest repository saw roughly 1 billion requests in August. These numbers show load growth across the whole platform. GitHub does not say how much of it comes from agents specifically. [1][3]
- The only performance evidence is one sentence: 'In internal benchmarks, it has delivered up to 35 times higher write throughput,' with read capacity scaling independently. The post describes no workload, repository size, concurrency level, baseline or latency distribution. It gives no rollout timeline and does not say whether any production repositories run on the new path. The Register calls the result 'early tests' and notes that Celenza offered no timeline for the migration. [1][3]
- The reliability background comes from GitHub's own reporting. The May 2026 availability report lists nine incidents, attributes traffic growth 'in large part' to AI-assisted and agentic workflows, and says Git traffic on Azure stood at 30% with repository replication at 99%. GitHub also says it more than doubled effective capacity in four months. The Register ties the Spokes rewrite to that record and cites 10 incidents in April. [4][3]

## What it means

The design is a familiar pattern: put durability in object storage, run stateless caching compute in front of it, and keep consensus only on the ref update. It targets the exact issue agent fleets create, where every push waits on the slowest of five replicas and adding read capacity slows writes. If it ships, single-push latency and write availability on hot monorepos should improve. Large CI fan-out reads should also stop competing with writes. Nothing in the post asks users to change workflows, and branch protections and audit logs are meant to carry over unchanged.

Builders should treat this as a plan, not a capacity guarantee. The 35x figure has no method, no latency numbers and no production status, so it is not a basis for sizing an agent fleet. For now, design agent systems to put less write pressure on shared repositories. Batch or squash checkpoints before pushing instead of pushing after every action. Spread work so thousands of agents are not hitting one hot ref. Use merge queues to serialize convergence. Back off and retry on push failures. Track GitHub's availability reports and the promised follow-up post for a migration timeline and real-world latency data before assuming the old limits are gone.

## Still open

- What workload, repository size, concurrency and baseline produced the '35x' write throughput result, and what happened to push latency (p50/p99)?
- Are any production repositories served by the new Blob Storage plus worker architecture yet, and what is the migration timeline?
- How are consistency and cold-cache latency handled when a new worker fills its cache from Blob Storage under heavy fan-out reads?
- What share of the reported growth in commits, pushes and Git events comes from agents rather than humans and CI?

## Sources

1. [Building Git infrastructure for agent-scale development (GitHub Blog, Oct 6, 2026)](https://github.blog/engineering/architecture-optimization/building-git-infrastructure-for-agent-scale-development) (primary)
2. [Stretching Spokes (GitHub Blog, 2017)](https://github.blog/engineering/infrastructure/stretching-spokes/) (primary)
3. [So long, Spokes: GitHub rewrites storage to restore reliability, just in time for agentic hordes (The Register)](https://www.theregister.com/devops/2026/10/09/so-long-spokes-github-rewrites-storage-to-restore-reliability-just-in-time-for-agentic-hordes/5302148)
4. [GitHub availability report: May 2026](https://github.blog/news-insights/company-news/github-availability-report-may-2026/) (primary)

Author: [Andrey Reshetnikov](https://newruntime.com/owner-profile.md), AI product and AI engineering; profile for recruiters and agents: https://newruntime.com/owner-profile.json

## Continue in the graph

Next records for an agent, linked to their Markdown twins. Replace `.md` with `.json` for structured fields, including `next_reads`.

- topic hub: [Github](https://newruntime.com/topics/github.md): Explore the github topic hub.
- topic hub: [Design](https://newruntime.com/topics/design.md): Explore the design topic hub.
- topic hub: [Agents](https://newruntime.com/topics/agents.md): Explore the agents topic hub.
- collection: [Analysis](https://newruntime.com/analysis.json): Open the latest authorial analysis.
- collection: [Source Ledger](https://newruntime.com/source-ledger.json): Inspect the public source evidence graph.
- whole graph: [discovery graph](https://newruntime.com/discovery-graph.json) (typed nodes and edges) and [site index](https://newruntime.com/site-index.md)