GitHub rebuilds Git hosting on Azure Blob Storage after commits grow fivefold

"An agent in a tight loop commits or checkpoints after nearly every action," GitHub engineer Brian Celenza wrote in the blog post explaining the rebuild ^[6]. Devops.com points out that through most of Git's lifetime, a commit recorded a decision: the developer pushed only once the change was done and checked, and hosting platforms were built around that rhythm ^[7].

Teams rolling out agents tend to picture a quick developer who still pushes finished work. GitHub's own figures describe a different user. Over the year, commits grew faster than merges, more than fivefold against nearly 4x ^[1][4]. Each merged pull request now carries roughly a quarter more commits than it did a year earlier ^[21].

Spokes, the current system, gets its strong durability by tying reads and writes together ^[8]. "Every replica participates in every write, so a push is only as fast as the slowest replica in its set," Celenza wrote ^[9]. He added: "Adding replicas to absorb read load makes writes slower." ^[10] Agents push on both sides of that at once. Concurrent loops keep the writes coming, and according to devops.com each push fans out into thousands of reads as CI pipelines clone the repository and code scanning starts ^[11].

In the new design, authoritative data sits in Azure Blob Storage and lightweight read workers sit in front of it, caching what requests need. Read capacity can grow without adding durable copies, and a failed worker is a cache miss ^[13]. "Compute workers can be added or removed as traffic changes instead of provisioning for peak load in advance," Celenza wrote ^[14].

The speedup GitHub describes is on its own write path. Downstream, GitHub Actions ran 3.26 billion times in September, four times the prior year ^[5]. That is about 2.4 billion more runs a month than the roughly 0.8 billion of a year earlier ^[20][22]. According to devops.com, when an agent's loop waits on push latency, the infrastructure caps the agent's speed ^[18]. Take away the wait and agents get to their next push sooner.

GitHub kept people in charge of review on purpose. Branch protections, required reviews, audit logs and repository visibility all stay ^[16]. Devops.com names CI costs, review bottlenecks and verification debt as the problems agent commits create for DevOps teams ^[17]. GitHub's published figures do not include review wait times, so the warning about longer queues is devops.com's judgement and has no measurement behind it yet.

For a platform lead, two counts per repository sort the exposure: how many pipeline runs one agent push triggers, and whether a human must approve before merge. With few runs and no required review, GitHub's rebuild covers most of the strain. Many runs without required review show up in the CI bill. Required review with few runs shows up as reviewer hours. Repositories high on both get the bill and the hours together. I think the first step is tagging agent pushes separately from human ones in CI reporting, before the new storage reaches your organisation. The catch is that batching agent checkpoints into fewer pushes, the obvious way to cut CI spend, gives back some of the latency gain GitHub is building.