Tigris recria o packfile do Git para rodar direto em object storage
Engenheira da Tigris Data desenhou um formato próprio de armazenamento para fazer o Git funcionar nativamente em buckets S3 e Azure Blob, sem depender de filesystem como camada intermediária.
O problema: Git foi desenhado para disco, não para bucket
O formato interno do Git parte de uma premissa simples: tudo vive num filesystem local, e o kernel pode fazer mmap dos arquivos de pacote (packfiles) para tratar o conteúdo do disco como memória. Ler um objeto específico custa nanosegundos porque o cache do sistema de arquivos resolve isso.
Object storage não tem esse luxo. Uma chamada GetObject custa, no mínimo, 10 milissegundos de round-trip de rede, ordens de grandeza mais lento que um acesso a disco local. É essa diferença que motivou Xe Iaso, engenheira da Tigris Data, a documentar em detalhe técnico no blog da empresa por que ela abandonou a abordagem óbvia (usar um filesystem shim sobre object storage) e reescreveu do zero o formato de packfile usado pelo objgit, o servidor Git open source↳Open source71 conteúdosComo o Open Source Está Liberando o Poder da Automação para TodosDev (Back & Front) · out 2025Código aberto: programadores criam software da NASA sem saberDev (Back & Front) · abr 2021N8N: O que é a ferramenta open source que está revolucionando a automação em TI?Dev (Back & Front) · dez 2025Ver tudo em Dev (Back & Front) → que a Tigris está construindo sobre sua própria infraestrutura de object storage.
O contexto de mercado importa aqui: como a própria autora observa, várias empresas estão lançando produtos de Git hospedado nos últimos meses, e a razão é a mesma para todas: rodar Git como serviço gerenciado, elástico e barato exige desacoplar o formato de armazenamento do pressuposto de "filesystem local" que o Git carrega desde 2005.
Por que o Range request não resolve sozinho
Um packfile guarda dezenas de milhões de objetos (blobs, trees, commits) comprimidos e concatenados num único arquivo binário, com um índice .idx separado que aponta o offset de cada objeto. Em tese, bastaria fazer um HTTP Range request para buscar só os bytes de um objeto específico dentro do bucket, sem baixar o packfile inteiro.
O problema é que o índice padrão do Git guarda o offset de início de cada objeto e o tamanho descomprimido, mas não o tamanho comprimido. Sem saber quantos bytes o objeto ocupa no arquivo, não dá para montar um Range request preciso: você sabe onde começar, mas não onde parar. Esse detalhe, sozinho, inviabiliza usar packfiles convencionais direto contra um bucket S3 de forma eficiente.
A solução: separar dados de metadados, como em CD de áudio
A saída que Iaso encontrou foi separar completamente dado de metadado, inspirada no formato .bin/.cue usado para backup de CDs de áudio e jogos multi-sessão (Dreamcast, Xbox 360). No objgit:
- Os objetos ficam concatenados, comprimidos com zstd, num arquivo
objects.binde até 128 MiB; - Um arquivo
objects.cueseparado guarda registros de tamanho fixo (58 bytes cada) com hash SHA-1, tipo, algoritmo de compressão, offset no.bin, tamanho comprimido, tamanho descomprimido e a referência ao objeto-base em caso de delta.
Com o tamanho comprimido explícito no .cue, o cliente calcula exatamente o Range request necessário e pede só aquele intervalo de bytes ao bucket, em vez de baixar o arquivo inteiro. A autora também mudou como deltas são armazenados: em vez de acoplados ao final do objeto original (como no packfile clássico do Git), cada delta vira um registro próprio no .cue, evitando ter que ler o objeto base inteiro só para chegar numa revisão específica.
Baixando enquanto lê: a corrida contra o feixe
Para reduzir latência na prática, o objgit usa uma estratégia que a própria autora descreve como corrida contra o feixe: sempre que a biblioteca Git pede um objeto de um packfile, o objgit começa a baixar o .bin inteiro para uma pasta temporária em segundo plano. Enquanto o download não chega à posição do objeto pedido, o cliente dispara Range requests pontuais direto no bucket; assim que o download de fundo ultrapassa aquele offset, os Range requests param de ser necessários.
Na prática isso significa que o custo de latência fica concentrado só na parte do arquivo ainda não baixada, e o restante já chega "de graça" pelo download sequencial que roda em paralelo.
O que muda pra quem constrói infraestrutura
Para quem mantém pipeline de CI/CD↳CI/CD23 conteúdosCI/CD Mobile: o caos invisível que separa times comuns de times de alta performanceDev (Back & Front) · abr 2026Lambda: implementando com GitLab CI/CD e Terraform para Integração SFTP, S3 e Databricks em GoDev (Back & Front) · nov 2023Publicando sua aplicação Web Python no WebApp do Azure e configurando o CI/CD da sua aplicaçãoDevSecOps · abr 2019Ver tudo em DevSecOps →, runners efêmeros ou servidores Git internos, a proposta ataca um ponto de atrito real: hoje, rodar Git em object storage geralmente significa montar um bucket via FUSE/gateway de filesystem, o que herda toda a lentidão que object storage tem para operações pequenas e aleatórias. Um formato nativo de object storage, como o que a Tigris descreve, abre a porta para:
- Clones parciais mais baratos: buscar só os objetos necessários para um checkout raso, sem precisar de um filesystem shim no caminho;
- Servidores Git elásticos: sem estado em disco local por repositório, o servidor pode escalar horizontalmente porque o "disco" é o bucket;
- Integração mais direta com pipelines cloud-native: runners de CI que já leem e escrevem em S3/Azure Blob poderiam, em tese, interagir com objetos Git sem camada extra de sincronização.
O ponto em aberto, que a própria autora reconhece implicitamente, é o de compatibilidade: esse .bin/.cue é um formato proprietário do objgit, não um packfile Git padrão, então qualquer servidor que o use precisa de uma camada de tradução para falar o protocolo Git com clientes normais (o git de linha de comando continua vendo um repositório Git comum do lado de fora). A justificativa dada é que, como Git é um sistema de controle de versão distribuído, cada clone já contém o histórico inteiro, então recriar o formato de armazenamento no lado do servidor é uma aposta de baixo risco: se der errado, basta reempacotar os dados a partir de qualquer clone existente.
O projeto ainda está em desenvolvimento e é aberto, o que significa que times que hoje rodam Gitea, Gitolite ou soluções self-hosted equivalentes sobre volumes em nuvem têm um caso de estudo concreto de como desacoplar Git de filesystem tradicional, algo relevante para quem opera infraestrutura própria no Brasil e paga IOPS ou storage em bloco mais caro que object storage puro.
Fonte: Hacker News
Este artigo foi escrito por Redação iMasters. Conteúdo produzido por agente de IA da redação iMasters, sob revisão editorial humana. Saiba como produzimos no expediente.
O editor-chefe da redação de agentes. Sem persona pública própria: assina como Redação iMasters. Monta a pauta do dia, distribui o mix entre verticais, revisa tudo que os especialistas escrevem, escreve notícias e compilados de opinião, e sugere taxonomia para revisão humana.
