GitHub bouwt Git-opslag voor duizenden agents tegelijk op één repository

GitHub bouwt de opslag achter Git opnieuw op omdat coding-agents het verkeer sterk laten groeien. In interne tests hield de nieuwe architectuur 5.000 agents tegelijk aan op één repository, met 7.200 pushes per seconde naar die repo terwijl lezen snel bleef. De opslag staat in een beperkte private preview; een bredere uitrol staat volgens GitHub gepland voor begin volgend jaar.

Voor wie zelf met agentic AI werkt, is dit vooral een teken van waar het verkeer heen gaat: niet één ontwikkelaar die af en toe pusht, maar tientallen of honderden agents die tegelijk branches aanmaken, committen en pull requests openen.

Waarom GitHub dit doet

In een eerste blogpost van oktober beschrijft GitHub de groei. De totale Git-activiteit steeg tussen september 2025 en augustus 2026 van 218,2 miljard naar 473,3 miljard gebeurtenissen per maand. In september maakten ontwikkelaars en agents 7,38 miljard commits, "more than five times as many as a year earlier". Het aantal pushes groeide in een jaar 4,9 keer, van 0,69 miljard naar 3,35 miljard per maand. De drukste repository kreeg in augustus ongeveer een miljard verzoeken.

Het huidige systeem, Spokes, bewaart volledige kopieën van elke repository op meerdere fileservers, standaard vijf. Elke kopie doet mee aan elke schrijfactie. Meer leescapaciteit betekent daardoor een extra volledige kopie, en elke extra kopie maakt pushen trager.

Wat er verandert in de architectuur

De tweede blogpost van 5 november legt het nieuwe ontwerp uit. GitHub vat de twee uitgangspunten samen als "minimize coordination, and decouple storage from compute".

• Alleen referenties hebben overeenstemming nodig. Git-objecten zijn onveranderlijk en krijgen hun naam van hun inhoud. Alleen het bijwerken van een referentie, zoals een branch, vraagt om coördinatie. Een apart gerepliceerd log regelt dat met compare-and-swap per referentie; een update telt zodra een meerderheid van de replica's hem heeft vastgelegd.
• Opslag los van rekenkracht. Packs, indexen en leesversnellers staan in Azure Blob Storage. De servers die verzoeken afhandelen houden alleen caches vast die weg mogen.
• Onderhoud buiten het serveerpad. Aparte achtergrondnodes voegen packs samen, zodat het aantal packs ongeveer gelijk blijft terwijl het aantal pushes groeit.

De cijfers uit de tests

Het zijn cijfers uit tests van GitHub zelf, geen metingen uit productie. GitHub mikte op minstens twee ordes van grootte meer schaal dan nu nodig is. Twee eerdere ontwerpen haalden dat niet: één write-ahead log in een enkele blob liep vast rond enkele honderden schrijfacties per seconde, en referenties verdelen over losse blobs maakte schrijven sneller maar lezen trager.

Wat dit betekent voor jouw werk met agents

Voor gebruikers verandert er volgens GitHub niets aan de werkwijze: er is geen onderhoudsvenster, en branchbeveiliging, verplichte reviews, auditlogs en zichtbaarheid van repositories blijven gelden. Het verschil merk je pas als je veel agents parallel op één repo laat werken, bijvoorbeeld met Claude Code, Codex of Copilot. Nu loop je dan eerder tegen wachttijden of geweigerde pushes aan; de nieuwe opslag moet dat opvangen.

Voor kleine teams blijft het praktische advies hetzelfde: laat agents op eigen branches werken, houd pull requests klein en laat een mens mergen. Het signaal kwam ook voorbij in de Radar van 7 november en de briefing van 7 november.

Wat we niet hebben gecontroleerd

We konden de cijfers niet zelf narekenen; ze komen uit de twee blogposts van GitHub. Wie toegang krijgt tot de private preview en onder welke voorwaarden, staat niet in de posts.

Gecontroleerd op 8 november 2026.

Dit artikel is geschreven met AI (Claude, Anthropic) en gecontroleerd tegen de bronnen hieronder.

Bronnen

• GitHub Blog, Building Git infrastructure for agent-scale development (Brian Celenza, 6 oktober 2026): github.blog
• GitHub Blog, Inside GitHub's new Git storage architecture (Karthik Raman, 5 november 2026): github.blog
• Aankondiging op X door @github: x.com/github