GitHub lancia Project Rubicon per migliaia di push al secondo

GitHub ha mostrato un repository con 5.000 agenti concorrenti e 7.200 push al secondo, con letture a bassa latenza. Il risultato arriva da test interni sulla nuova architettura di storage Git annunciata a GitHub Universe la scorsa settimana¹.

Il progetto si chiama Rubicon. GitHub lo ha avviato nel maggio 2026, subito dopo la prima migrazione su Azure. L’obiettivo: sostenere almeno due ordini di grandezza in più di scala verticale per singolo repository rispetto allo stato attuale¹. La base tecnologica resta quella del ciclo di post precedenti: minimizzare la coordinazione e separare storage e compute. La migrazione del 99,99999% dei repository su Azure ha preparato il terreno, insieme alle repliche virtuali e al quorum di scrittura per singolo riferimento¹.

Solo gli aggiornamenti di riferimento richiedono accordo. Gli oggetti Git sono immutabili e content-addressed, quindi più writer possono salvarli in parallelo senza coordinarsi. Questo consente di scalare in modo indipendente conservazione dei dati, servizio delle richieste e manutenzione dei repository. Per chi sviluppa, Git non cambia: push, fetch e branch funzionano come prima, con le stesse protezioni¹.

Il sistema scala verticalmente. Deve accettare migliaia di scritture al secondo su un singolo repository, mantenere bassa la latenza di commit e permettere a ogni componente di crescere separatamente. Gli aggiornamenti devono restare ordinati per riferimento, con la possibilità di linearizzare rapidamente tra riferimenti. Una replica virtuale in ritardo deve scaricare solo i dati necessari per servire la richiesta in arrivo. Le letture devono restare economiche quando non ci sono cambiamenti, il caso più comune per via dell’alto rapporto read-write¹.

Rubicon supporta più nodi writer per due motivi precisi. L’indicizzazione dei pack in ingresso e il controllo di connettività sono le fasi più costose in CPU, e il costo scala con la dimensione della scrittura. Un singolo nodo andrebbe presto in saturazione. Distribuire il lavoro su più nodi migliora anche la tolleranza ai guasti e riduce i tempi di recupero in caso di failure di un writer¹.

Il dato grezzo vive in Azure Blob Storage. In alcune esplorazioni, GitHub ha provato a tenere lì anche lo stato dei riferimenti, ma ha scelto un disegno che massimizza il throughput senza perdere correttezza, durabilità, disponibilità e latenza richieste dalla piattaforma. Le richieste arrivano a Spokes, che mantiene il ruolo di routing, bilanciamento e placement. Qui restano le garanzie di partizionamento dei tenant, isolamento e fairness per la scala orizzontale¹.

Le repository più trafficate oggi vedono al massimo decine di scritture al secondo, spesso a raffiche. Con agent che lavorano in parallelo e senza sosta, quelle raffiche diventeranno un flusso sostenuto. Ogni push moltiplica le letture: CI, sistemi di deploy, altri agent che fetchano per contesto. L’effetto ventaglio sulle letture cresce con la velocità delle scritture e obbliga a pianificare subito per carichi due ordini di grandezza superiori¹.

Un repository osservato tra marzo e maggio ha quadruplicato le richieste giornaliere, e il trend è proseguito in modo esponenziale dopo quel periodo. Rubicon nasce per questo scenario e viene implementato mentre GitHub resta operativo per gli utenti finali¹.

Una replica virtuale che resta indietro può recuperare scaricando solo i dati necessari per la richiesta in arrivo¹.