OpenAI ha scritto un nuovo backend Git, si chiama Pando

OpenAI ha messo in produzione ad aprile Pando, un backend Git interno. Secondo l’azienda ha ridotto la latenza delle push di quasi 5 volte e oggi serve quasi un petabyte di dati al giorno¹. Nel frattempo i commit trimestrali nel monorepo, entro fine anno, cresceranno di oltre il 2.400% rispetto al primo trimestre 2024¹.

Il team ha scelto di restare nel mondo Git. L’affidabilità del vecchio backend era scesa sotto il 90%, con fetch lenti e merge falliti. La domanda è stata chiara: il limite stava in Git o nel modo in cui servivano il monorepo. La risposta ha puntato sull’architettura del server, non sul client o sul protocollo¹.

Pando rimuove due vincoli comuni nei server Git: non impone coerenza simultanea tra tutti i branch e non costruisce un packfile personalizzato per ogni fetch¹. In Git un branch è un puntatore all’ultimo commit. Muovere quel puntatore è l’unica operazione che richiede coordinamento. Pando gestisce ogni branch in modo indipendente, così le push su rami non correlati non si intralciano. Il prezzo è una possibile vista sfalsata tra branch quando li si osserva insieme, ma a chi sviluppa interessa l’ordine interno al singolo ramo¹.

Durante una push, Pando valida il packfile mentre lo scrive in blob storage, senza scompattarlo in un repository locale. Registra il nuovo tip, la posizione del pack e le dipendenze in un metastore. Per impostazione predefinita pubblicizza solo trunk come base per le feature branch. In questo modo ogni pack resta riutilizzabile da client che possiedono già la storia di trunk¹.

Nel fetch, Pando seleziona i pack archiviati in base alla storia del client e restituisce link tramite packfile-uri. Un servizio di caching, Express, distribuisce i pack da cache regionali con un hit rate sopra il 99%. Su VM cloud standard, clone e fetch saturano link da 10 Gbps, afferma l’azienda¹.

Un monorepo attivo produrrebbe altrimenti decine di migliaia di pack piccoli al giorno. Processi in background li fondono in pack più grandi nel tempo, in modo simile alla compattazione di un database log-structured. Questo consente anche di calcolare i pack necessari a un client in tempo logaritmico. Pando conserva i pack a ogni livello di compattazione e serve da tutti, senza garbage collection distruttiva¹.

Il confronto con i server Git tradizionali chiarisce il guadagno: ogni fetch tipicamente richiede calcolare gli oggetti mancanti e comprimere un pack dedicato, costoso da generare e difficile da mettere in cache. Prima della push, il server elenca tutti i branch per evitare duplicati, ma con milioni di rami la lista supera i 100 MiB. Pubblicizzare solo trunk evita questo costo, con la conseguenza che push ripetute sullo stesso ramo rispediscono quanto non sta su trunk. Per OpenAI è un compromesso accettabile: la mediana dei pack nel monorepo resta sotto i 20 KiB¹.

Pando è scritto in Rust. OpenAI riferisce di averlo progettato e costruito in circa dieci settimane, con un ingegnere autore del core e squadre di agenti Codex sull’implementazione. Sviluppatori e agenti continuano a usare comandi Git standard. OpenAI distribuisce una propria build di Git sui laptop interni e nell’app desktop di ChatGPT¹.

Il lavoro tocca anche Git upstream. Pando si appoggia molto a packfile-uri, proposta di un ingegnere Google del 2019, e OpenAI sta inviando correzioni al progetto¹. Intorno, l’ecosistema accelera: GitHub ripensa l’infrastruttura per servire miliardi di pull request al mese, nascono startup come Entire e progetti come Origin, mentre altri, tra cui Anthropic, riscrivono client e architettura da zero. Il messaggio è semplice: il ritmo di sviluppo costringe a rivedere gli strati fondamentali del controllo versione, partendo dai colli di bottiglia reali¹.