Brian Celenza, Principal Software Engineer bei GitHub, schrieb am 6. Oktober im offiziellen Engineering-Blog, dass das Unternehmen seine Git-Speicherschicht neu aufbaut. Der Grund wird unverblümt genannt: KI-Agenten haben den Schreibverkehr an die Obergrenze der bisherigen Architektur getrieben. In internen Benchmarks erhöht die neue Architektur den Schreibdurchsatz um bis zu 35x.
Der Artikel nennt eine Reihe von Wachstumszahlen aus dem vergangenen Jahr:
| Kennzahl | Aktueller Wert | Jahresveränderung |
|---|---|---|
| Git-Ereignisse pro Monat | 473,3 Mrd. (August 2026) | ca. 2,2x |
| Pushes pro Monat | 3,35 Mrd. | 4,9x |
| Commits pro Monat | 7,38 Mrd. (September 2026) | über 5x |
| Actions-Läufe pro Monat | 3,26 Mrd. (September 2026) | über 4x |
| Gemergte PRs | kein Absolutwert genannt | fast 4x |
Das am stärksten ausgelastete einzelne Repository erhielt im August rund 1 Milliarde Anfragen. Das Schreibverhalten der Agenten wird im Artikel so beschrieben:
"An agent in a tight loop commits or checkpoints after nearly every action" (Ein Agent in einer engen Schleife committet oder setzt nach fast jeder Aktion einen Checkpoint.)
Die alte Architektur stößt beim Schreiben an ihre Grenzen
GitHubs bestehendes Speichersystem für Repositories heißt Spokes. Standardmäßig wird jedes Repository als vollständige Kopie auf den lokalen Festplatten mehrerer Dateiserver gespeichert, insgesamt fünf Kopien. Wenn ein Push eine Referenz aktualisiert, sorgt ein mehrheitsbasiertes Drei-Phasen-Commit-Protokoll dafür, dass CI, Web-Oberfläche und API-Clients einen konsistenten Repository-Zustand sehen.
In diesem Design übernehmen die Kopien zwei Aufgaben gleichzeitig: Datenverlust verhindern und Leseanfragen verteilen. Der Preis dafür: Jede Kopie muss an jedem Schreibvorgang teilnehmen – mehr Kopien ermöglichen mehr Lesezugriffe, machen das Schreiben aber langsamer. In der Ära, in der menschliche Entwickler den Takt vorgaben, überwogen Lesezugriffe die Schreibzugriffe bei weitem, sodass dieser Kompromiss unproblematisch war. Seit Agenten die Schreibfrequenz hochtreiben, ist die Anzahl der Kopien zum Flaschenhals beim Schreiben geworden.
Die neue Architektur gliedert sich in drei Teile
Der erste Teil besteht darin, die Koordination auf ein Minimum zu reduzieren: Nur die Aktualisierung von Referenzen erfordert noch Einigkeit zwischen allen Beteiligten, Objektspeicherung, Validierung und Sicherheitsscans laufen jetzt parallel.
Der zweite Teil ist die Trennung von Speicherung und Berechnung. Die Persistenz übernimmt Azure Blob Storage, Leseanfragen werden von einer Gruppe leichtgewichtiger Worker-Prozesse bedient. Im Artikel heißt es dazu:
"Separating the two lets us scale each one independently" (Die Trennung beider Teile erlaubt es, jeden unabhängig zu skalieren.)
Der dritte Teil ist die Auslagerung der Hintergrundwartung: Kompression und Garbage Collection laufen auf eigenen Worker-Prozessen und konkurrieren nicht mehr mit Echtzeit-Anfragen um Ressourcen. Kontrollmechanismen wie Branch-Schutz, erzwungene Reviews, Audit-Logs und Observability bleiben erhalten.
Eine grobe Rechnung zum Schreibvolumen
Grob gerechnet auf Basis eines 30-Tage-Monats entsprechen 7,38 Milliarden Commits etwa 2.850 pro Sekunde; 3,35 Milliarden Pushes entsprechen etwa 1.290 pro Sekunde, gegenüber rund 270 vor einem Jahr. Müsste jeder Push alle 5 Kopien einbeziehen, hätte die alte Architektur pro Sekunde rund 6.500 Kopien-Schreibvorgänge zu bewältigen (Schätzung, ohne Wiederholungsversuche und Wartungsaufgaben).
Die 35-fache Durchsatzsteigerung steht einer jährlichen Push-Wachstumsrate von 4,9x gegenüber und lässt rechnerisch mehrere Jahre Spielraum. Voraussetzung ist, dass sich die Wachstumskurve des Agenten-Verkehrs nicht weiter verschärft – und auch dafür liefert GitHub selbst keine Prognose.
Was der Artikel offenlässt
Wie viele Repositories bereits auf die neue Architektur migriert wurden und wann die vollständige Umstellung erfolgt, nennt der Artikel nicht; auch zu Größe und Parallelität des Repositories, auf dem der 35x-Benchmark beruht, fehlen Angaben. Mögliche Auswirkungen für Nutzer, etwa ob sich Rate Limits ändern, werden ebenfalls nicht erwähnt.
GitHub hatte dieses Jahr mehrere längere Serviceunterbrechungen; der Artikel geht auf diese Vorfälle nicht ein und sagt nicht, ob die neue Architektur Ähnliches verhindern könnte. Celenza kündigt am Ende an, dass der nächste Teil der Serie näher auf die künftige Architektur und den Hintergrund dieses Umbaus eingehen wird.
Quellen: GitHub Engineering Blog, CocoLoop; offizielle GitHub-Daten wurden zur Prüfung der monatlichen Zählweise von Commits, Pushes und Actions-Läufen herangezogen.