GitHub heeft 99,99999 procent van alle repo's gekopieerd naar Azure

GitHub heeft inmiddels 99,99999 procent van de repository's gekopieerd naar Azure. Het bedrijf werkt al langer aan een migratie naar het cloudplatform van moederbedrijf Microsoft. Het kleine aantal overgebleven repo's is extreem druk, wat de overstap moeilijker maakt.

Dit nieuws in het kort

• Inmiddels zijn 99,99999 van alle GitHub-repository's gekopieerd naar Microsoft Azure, zegt het ontwikkelaarsplatform.
• De overige 0,00001 procent bestaat uit extreem drukke repo's, wat na de overstap zou zorgen voor extra vertraging bij schrijfacties.
• GitHub werkt aan een manier om meerdere schrijfacties tegelijkertijd toe te laten, wat die problematiek moet oplossen.

GitHub zegt dat de overstap naar Azure wordt gedreven door een aantal zaken, vooral de opkomst van AI-agents. Het netwerkverkeer neemt daardoor explosief toe, terwijl GitHub een harde limiet heeft op het stroomgebruik in zijn eigen datacenters en de omliggende gebieden.

De eerste kopie van een repository kwam in augustus 2025 binnen in de Azure-regio Central US. De meeste repo's hebben vijf kopieën, waarvan inmiddels meestal twee in Azure, aldus GitHub. Het moet nu dus gaan om 99,99999 procent van de GitHub-repo's.

De overgebleven 0,00001 procent is nog niet overgestapt vanwege netwerkvertraging. Het gaat om de drukste repository's op het GitHub-platform. Repo's die in meerdere regio's zijn opgeslagen, zoals degene die gekopieerd zijn naar Azure, hebben een lagere throughput voor schrijfacties. Dat kan bij die repo's voor problemen zorgen.

GitHub kopieerde repository's stapsgewijs naar Azure-servers. Beeld: GitHub

Roundtrips en vertraging

De huidige opbouw zorgt ervoor dat de langzaamste kopie van GitHub-data de vertraging bepaalt voor iedere schrijfactie. Tegelijkertijd zet iedere schrijfactie de complete repository vast, waardoor andere acties moeten wachten.

GitHub zegt dat replica's in de beoogde Azure-regio's op ongeveer 1600 kilometer afstand liggen. Dat zorgt voor een netwerkroundtrip van 25 milliseconde, oftewel 0,025 seconden. Voor iedere schrijfactie zijn meerdere roundtrips nodig. Bij drukke repository's die al dichtbij hun throughputplafond zitten, zou dat voor een vertraging zorgen die bij iedere nieuwe actie blijft oplopen.

Nieuwe architectuur

In een toekomstige update verandert GitHub daarom de architectuur. Niet langer zorgt een schrijfactie voor een lock op een complete repository. Voortaan moeten alleen schrijfacties op elkaar wachten die dezelfde referenties als doel hebben.

Iedere schrijfactie heeft hierna nog steeds de roundtripvertraging, maar er kunnen in de praktijk meerdere acties tegelijkertijd uitgevoerd worden. Dat moet de problemen oplossen. Op basis van eerste tests zegt GitHub dat dit een drie tot vier keer zo hoge schrijfcapaciteit oplevert.

Dit moet het op termijn mogelijk maken om ook deze laatste repository's over te zetten naar Azure, zonder de genoemde prestatieproblemen. GitHub noemt geen specifieke deadline voor wanneer de overstap 100 procent voltooid is, maar de uitrol van de nieuwe architectuur gebeurt volgens het platform stapsgewijs.

De nieuwe architectuur voor schrijfacties moet zorgen voor minder vertragingen. Beeld: GitHub

Overstap naar Azure

GitHub werkt al langer aan een migratie naar Azure vanwege het genoemde gebrek aan datacentercapaciteit. Het ontwikkelaarsplatform werd voorheen gehost op de eigen hardware in de Amerikaanse staat Virginia.

Het bedrijf zei een jaar geleden dat de overstap in totaal twee jaar in beslag gaat nemen. Inmiddels zijn we een jaar verder en is het gros van de repository's dus al gekopieerd naar Azure.

Reacties (28)

[lenwar]

Je zou toch verwachten dat ze op een bepaald moment die laatste repos gewoon even downbrengen voor de migratie. Gewoon een paar weken/maanden van te voren inplannen en gaan.

Edit: Ik las het verkeerd. Ik las het als dat de 'migratie' te lang zou duren om zonder downtime te kunnen migreren. Maar er staat inderdaad dat het platform niet snel genoeg is (qua latency) om die high-volume repo's te kunnen hosten.
@aikebah bedankt voor de correctie

[Reactie gewijzigd door lenwar op 22 oktober 2026 20:38]

[aikebah]

Als het zou gaan om "tijd nodig hebben voor de final sync" zou dat een optie zijn, maar de uitleg in het artikel wijst op "azure storage latency is te hoog" (bij full repository-lock op een write-actie (git push)) voor deze repo's, waardoor de repo's na migratie "onbruikbaar" worden (iedere git push verhoogt de queue-tijd voor alle andere wachtende pushes omdat de push-frequentie hoger ligt dan de write-acties serieel-per-repo bij kunnen houden)

[lenwar]

Je hebt helemaal gelijk. Ik had het verkeerd gelezen. Ik dacht te lezen dat het om de migratie ging. Niet om de beoogde eindsituatie. Blijkbaar vinden sommigen mijn leesfoutje 'Ongewenst'

[Reactie gewijzigd door lenwar op 22 oktober 2026 20:21]

[Lennie]

Ik las het als: Azure schijf acties zijn niet snel genoeg vanwege de groottee afstand tussen Azure datacenters voor deze repos.

[Reactie gewijzigd door Lennie op 22 oktober 2026 20:38]

[seppdroid]

Een hogere percentage dan de uptime, even zonder dollen. De hoeveelheid traffic die met AI gegenereerd wordt is bizar. Dat het allemaal nog draait is al wat. Zeker gezien de oude hobbyprogrammeur vroeger een paar statische repo's had maar nu een vibeproject honderden tests heeft en een github automation waar je u tegen zegt

[GewoonWatSpulle]

En net als de token binnen een uurtje door je budget heen gerookt, meer tests maakt niet voor een beter project, goede tests die op het juiste moment gedraaid worden zijn en blijven meer waard.

[Liveonline]

even van host veranderen is niet zomaar iets wat je doet helaas, vaak is de sync van de oude host naar de nieuwe host een drama gezien je 2 sites up to date moet houden en je niks verloren wilt laten gaan en zie maar eens te checken dat alle data is 100% gekopieerd en niet wat gemist is.

[cosmo_roel]

Welke repos zijn zo druk dan?

[Powerblast]

Vraag ik me ook af. Blijkbaar zijn er dan repos die extreem druk beschreven worden elke seconde? Wel benieuwd de welke, want zelfs bij repos van de grotere projecten zit er toch altijd wel wat tijd tussen elke commit.

[The Realone]

Ik denk dat het om een combinatie van zeer drukke repos gaat en de replicatie daarvan naar andere regios. Dan kun je het ineens over minuten hebben. Een aantal LLM repos hebben extreem veel activiteit, alsmede bijvoorbeeld winget-pkgs waarbij elke package update een PR is. Maar ook bijvoorbeeld projecten als kubernetes die gewoon een enorme community hebben met extreem veel onderdelen.

[Powerblast]

Zal het idd wel zijn. Dacht er pas net aan dat issues en pr natuurlijk ook deel zijn van een repo. Dan loopt de activiteit natuurlijk snel op.

[satya]

Dat zijn niet alleen repo's vermoed ik maar complete ontwikkel omgevinen die ook in test en acceptatie omgevingen microservices draaien en waar binnen git ai gedreven code wordt geproduceerd.

GitHub is heel veel meer dan Git alleen.

[Kewne]

Ik denk dat spul als nixpkgs ergens in die regio zit. Ze vieren bijna commit nummer 1.1 miljoen op de ontwikkelbranche, hebben nog altijd meerdere branches en hebben daarnaast veel activiteit in forks & PRs, welke allemaal onder dezelfde 'fysieke' repository zitten in GitHub's ontwerp (in ieder geval in het oude ontwerp, weet niet of dat na deze Azure migratie anders is). Dat gaat rap genoeg dat er op piekmomenten een soort van wachtrij kan ontstaan.

[RusFighter]

https://github.com/php/php-src

[maddog4004]

Hoelang duurt het voordat microsoft ook je credit card gaat vragen voor github access?

[Sp3ci3s8472]

Of een Microsoft account.

[willieverhoef]

Want? Je heb liever google, icloud of GitHub. Ieder account heeft nadelen. Maar de toekomst is wel dat het niet uitmaakt waar je je account is. Het is gewoon open voor iedereen waarschijnlijk.

[Sp3ci3s8472]

Ik heb al een Github account, ik hoef gen MS account. Wat heb ik aan al die extra onzin die erbij komt. Liever heb ik ook geen Google account, mjah voor Playstore heb je dat nodig. Ik zou inderdaad eerder voor Apple kiezen dan voor Google, maar zolang GrapheneOS nog kan blijf ik bij Android. Is dat niet meer mogelijk dan ga ik voor een iPhone waarschijnlijk, dan kan ik alle Google dingen helemaal verwijderen.

[Diablow]

Ik zit ook op Codeberg. Maar die hebben hun voorwaarden aangepast waardoor je het niet meer mag gebruiken als bijna alle code door AI wordt geschreven. Dus bijna helemaal weer terug op GitHub..

[Sp3ci3s8472]

Waarom niet gitlab, ci/cd is daar erg sterk.

[BasHouse]

Is die php repo de 0,000001 procent? Ja.

[DJMaze]

Ik vraag mij af hoelang dit nog stand houdt.
Via Firefox en Chromium is de website nu zo gigantisch traag.
Maar dat lijkt vooral aan de berg slechte JavaScript te zijn (AI misschien?).
Gelukkig werken Firefox en Github aan een mogelijke oplossing, anders zullen er vast meer repos vertrekken.

[Giga_]

Herken wel dat Azure haar kracht zeker niet ligt in hoge data snelheden. Dat is bij sommige solutions zo armzalig traag

[Netburst]

Is er bekend hoe veel traffic Github doet per maand?

[Snow_King]

Ik denk dat het nog wel eens tegen kan vallen. Ja, het zal veel verkeer zijn, maar Git is veelal tekst, dat is niet zo bizar veel verkeer.

Natuurlijk, Github is mega! Maar het zal in het niets vallen bij Netflix, YouTube, etc.