GitHub detalha Rubicon, nova arquitetura de armazenamento Git que separa objetos e referências

O GitHub apresentou o Rubicon, nova arquitetura de armazenamento Git que separa duas coisas com perfis bem diferentes: os objetos Git, que são imutáveis e ficam no Azure Blob Storage, e as atualizações de referências, registradas em um log replicado dedicado. Como cada parte vive numa camada própria, compute, armazenamento e manutenção escalam de forma independente.

Nos testes internos, a arquitetura suportou 5.000 agentes simultâneos e 7.200 pushes por segundo para um único repositório. As requisições foram atendidas por réplicas virtuais descartáveis, e workers separados cuidaram da compactação dos packs. O contexto do post é a reconstrução da infraestrutura Git do GitHub com a plataforma no ar, voltada ao desenvolvimento em escala de agentes. A página do blog cita que uma cópia de 99,99999% dos repositórios já foi movida para o Azure.

Em 22 de outubro de 2026, o CEVIU noticiou "GitHub detalha caminho para uma infraestrutura Git em escala de agentes", sobre como os per-reference quorums levariam o restante dos repositórios ao Azure. Em 28 de outubro de 2026, em "GitHub adota quorums por referência para escalar a infraestrutura Git na era dos agentes", o foco foi a troca da serialização de escritas em todo o repositório por quorums por referência, com throughput de 3 a 4 vezes maior em escrita nos testes internos. Em 5 de novembro de 2026, veio a matéria sobre a reconstrução sem tirar a plataforma do ar. Agora o detalhamento chega à camada de armazenamento: objetos no Azure Blob Storage, referências em log replicado e números de carga com 5.000 agentes e 7.200 pushes por segundo.

Para quem opera ferramentas que disparam muitos agentes sobre o mesmo repositório, o recado é que o gargalo de escrita concentrada em um repo está sendo atacado na base. É uma leitura editorial: os números são de testes internos, e o impacto prático para usuários dependerá de como e quando isso chegar à plataforma.