Durante quase duas décadas, a unidade atômica de memória da engenharia de software foi o commit do Git. O modelo desenhado por Linus Torvalds em 2005 parte de uma premissa clara: humanos editam arquivos localmente em silêncio, testam hipóteses, descartam tentativas frustradas e, quando chegam a um estado coerente, empacotam um snapshot imutável acompanhado de uma mensagem de texto explicando a intenção da mudança.

Na era da programação assistida por agentes autônomos, essa premissa ruiu. O volume de código produzido por minuto cresceu em ordens de grandeza, e o processo de clarificação arquitetural — as restrições discutidas, os trade-offs rejeitados e as instruções que deram origem a cada função — deixou de acontecer apenas na cabeça do desenvolvedor ou em revisões de Pull Request. Hoje, o raciocínio por trás do código nasce dentro de threads de conversação com agentes.

Quando essa sessão vira um commit tradicional, o contexto se perde: na melhor das hipóteses, fica preso no histórico proprietário do harness usado naquele dia; na pior, evapora em uma mensagem de commit genérica gerada pelo próprio modelo que ninguém leu.

Para atacar essa lacuna estrutural sem exigir que as equipes abandonem o Git, a Zed Industries — criadora do editor Zed e do ambiente agêntico Delta — revelou a arquitetura interna do DeltaDB, detalhada em um artigo técnico assinado por Antonio Scandurra (@as__cii), cofundador da empresa. Escrito em Rust, armazenado localmente em SQLite e sincronizado na borda via Cloudflare Durable Objects, o DeltaDB funciona como um sistema de controle de versão de granularidade fina que unifica edições de código, mensagens de conversa, comentários e árvores de arquivos em um único grafo causal contínuo.

No DeltaDB, cada edição de texto, mensagem enviada ao agente, comentário de revisão e alteração na árvore de arquivos torna-se um delta no mesmo grafo causal.

O problema entre os commits: por que o Git não basta para múltiplos agentes

O Git continua insubstituível para publicar histórico consolidado, gerenciar branches oficiais e acionar pipelines de CI/CD. Mas usar commits e git worktree como mecanismo de coordenação em tempo real entre humanos, subagentes locais e cloud runners esbarra em três gargalos severos:

  1. Amnésia de contexto entre commits: Se um agente reescreve um módulo inteiro na mensagem #14 da conversa e quebra um invariante sutil na mensagem #19, voltar exatamente ao estado da árvore de arquivos na mensagem #14 exige que alguém tenha feito commits manuais a cada turno.
  2. Explosão de diretórios e bloqueio de branches no git worktree: O Git nativo impede que duas worktrees façam checkout da mesma branch simultaneamente e exige cópias físicas completas do repositório no disco para cada agente paralelo, multiplicando o tempo de setup e limpeza.
  3. Colaboração cega antes do Pull Request: Compartilhar uma tarefa em andamento com um colega de equipe enquanto o agente ainda está editando arquivos exige fazer commits sujos (WIP) e empurrar branches temporárias para o repositório remoto.

A abordagem do DeltaDB separa claramente as responsabilidades: o Git guarda os commits; o DeltaDB guarda tudo o que acontece entre eles. Quando você aponta para uma linha de código, consegue rastrear qual delta específico gerou cada caractere e saltar diretamente para o trecho exato da conversa — humana ou de um agente — que motivou aquela alteração.

Grafo Acíclico Dirigido (DAG), CRDTs e a herança do algoritmo Eg-walker

Por baixo do capô, o DeltaDB modela todo o estado de uma agent thread — transcrição da conversa, arquivos da worktree, metadados e comentários — como uma coleção de CRDTs (Conflict-free Replicated Data Types) encadeados em um Grafo Acíclico Dirigido (DAG) monotônico.

Cada nó desse grafo é chamado de delta, a menor unidade indivisível de mudança no sistema. Ao adotar CRDTs, qualquer cliente (o app nativo, a CLI, um subagente ou um navegador web) pode aplicar mutações localmente com latência zero, operar offline durante falhas de rede e convergir de maneira determinística assim que a conexão for restabelecida, independentemente da ordem em que os pacotes cheguem.

O design do DeltaDB inspira-se no algoritmo Eg-walker: a versão completa do sistema é expressa apenas pelos deltas na fronteira (tips) do grafo.

Fronteiras compactas vs. Vetores de Versão (Version Vectors)

Uma decisão arquitetural decisiva revelada por Scandurra foi rejeitar vetores de versão tradicionais (version vectors e dotted version vectors) em favor da navegação direta de ancestralidade no DAG, seguindo de perto o modelo introduzido por Joseph Gentle e Martin Kleppmann no artigo científico Eg-walker (Event Graph Walker).

Em sistemas colaborativos clássicos, um vetor de versão mantém um contador numérico para cada ator (actor_id -> seq), permitindo verificar em $O(1)$ se uma versão já incorpora outra. Contudo, esse modelo pressupõe que os atores são poucos e longevos. Em um fluxo de engenharia com IA, humanos abrem e fecham sessões e subagentes efêmeros nascem e morrem a cada minuto. Uma vez que um subagente emite um único delta, seu contador jamais pode ser removido do vetor de versão sem risco de ambiguidade — fazendo o metadado crescer indefinidamente.

No DAG do DeltaDB, o estado completo do sistema em qualquer instante é representado apenas pelos deltas nas pontas abertas do grafo (a frontier). O tamanho dessa fronteira cresce proporcionalmente ao número de ramificações concorrentes abertas naquele exato momento, e não ao total histórico de agentes que já escreveram na thread. Para tornar as consultas de ancestralidade rápidas sem vetores de versão, o DeltaDB armazena a topologia dos pais de cada delta separadamente do seu payload, em ordem estritamente causal, aproveitando ao máximo a localidade de cache no SQLite.

Desacoplando a representação de rede da estrutura interna

Como cada delta aponta explicitamente para a versão-pai sobre a qual foi construído, sua representação na rede pode ser extremamente enxuta. Uma edição de texto, por exemplo, resume-se a três campos em Rust:

struct EditTextDelta {
    parent: Version,
    offset: usize,
    text: String,
}

Na imensa maioria das vezes, o buffer local já está na versão parent, e a inserção no offset ocorre diretamente. Se uma edição concorrente tiver avançado o buffer nesse meio-tempo, o cliente reifica (reconstrói) a versão exata de parent, traduz o offset numérico para o identificador interno de fragmento (fragment ID, similar ao motor de texto do Zed) e localiza onde esse fragmento se encontra na versão atual. Isso reduz drasticamente o tráfego de rede e permite paginar fragmentos inativos para fora da memória.

A árvore B+ Copy-on-Write em SQLite: superando a SumTree do Zed

Como a aplicação de edições concorrentes, o scrubbing instantâneo pela linha do tempo da conversa e a montagem de worktrees antigas no disco dependem da capacidade de reconstruir qualquer versão do DAG em milissegundos, o armazenamento local em SQLite precisou de uma engenharia própria.

O DeltaDB mantém snapshots em cache para os nós recentemente acessados no DAG (além de versões-chave fixadas). Quando precisa materializar uma versão arbitrária, ele caminha para trás no grafo até o ancestral mais próximo com snapshot em cache e aplica apenas os deltas intermediários.

Para que guardar dezenas de snapshots no SQLite não exploda o consumo de disco, todo o estado versionado é estruturado como árvores B+ Copy-on-Write (CoW). Assim, um novo snapshot compartilha estruturalmente quase todos os nós da árvore anterior, alocando novas linhas apenas para o caminho modificado pelos deltas recentes.

Diferente da SumTree puramente imutável do Zed, a árvore B+ do DeltaDB realiza mutações in-place via cursor mutável antes do commit na tabela nodes do SQLite.

Curiosamente, a equipe não reutilizou a famosa SumTree do editor Zed sem modificações. No Zed, a SumTree é uma árvore B+ estritamente append-only: para editar um item no meio da árvore, é preciso fatiar o prefixo até o ponto de inserção, empurrar os novos elementos e concatenar o sufixo, reconstruindo todos os nós ao longo do corte.

No DeltaDB, em que cada nó da árvore corresponde a uma linha na tabela genérica nodes do SQLite, reconstruir prefixos e sufixos geraria um volume excessivo de escritas em disco. A solução foi projetar uma árvore B+ com cursor mutável (in-place mutation), rastreando com precisão cirúrgica o ciclo de vida de cada nó durante uma transação:

  • Nós recém-alocados viram instruções INSERT na tabela nodes;
  • Nós modificados na mesma versão são reescritos diretamente na linha existente (UPDATE);
  • Nós liberados têm apenas seu contador de referências (refcount) decrementado, preservando a integridade dos snapshots anteriores que ainda apontam para eles.

Timelines, sincronização logarítmica e um Durable Object por Thread

Para coordenar agentes trabalhando em paralelo sem tocar no Git, o DeltaDB introduz o conceito de Timelines. Sempre que um agente principal dispara um subagente para investigar ou refatorar um subsistema, o cliente cria uma nova timeline estacionada na fronteira (frontier) atual da thread-mãe. O subagente faz suas alterações de forma isolada dentro do mesmo DAG e, ao terminar, sua timeline é mesclada de volta sem necessidade de commits intermediários ou branches órfãs no Git.

Quando uma thread é compartilhada entre desenvolvedores ou cloud runners, a sincronização ocorre via WebSockets:

  1. Ao conectar (ou reconectar após queda de rede), cliente e servidor trocam uma lista logaritmicamente espaçada de versões caminhando pelo DAG até localizar um ancestral comum recente;
  2. Apenas os deltas ausentes de cada lado são transmitidos;
  3. A partir daí, cada novo delta é transmitido incrementalmente em tempo real para todos os assinantes daquela timeline.

Arquitetura Share-Nothing na borda da Cloudflare

No lado do servidor, a Zed adotou um isolamento radical: cada thread do DeltaDB é sincronizada com a sua própria instância de Cloudflare Durable Object.

  • O Durable Object só é instanciado na primeira vez em que um cliente se conecta à thread — criar uma thread local tem custo zero no servidor;
  • Com exceção da autenticação inicial (apoiada em Postgres), a arquitetura é 100% share-nothing: não há um banco de dados centralizado disputando locks entre milhões de sessões simultâneas de agentes;
  • Embora rode hoje na infraestrutura multi-tenant da Zed e em implantações Bring Your Own Cloudflare (single-tenant corporativo), o backend foi abstraído para ser portável a qualquer nuvem que ofereça Object Storage, Postgres e processos single-threaded endereçáveis com armazenamento transacional próprio.

#[derive(Replicate)] e o orçamento de 8 ms na interface nativa

Para que os próprios engenheiros do Delta não precisem manipular nós de DAG ou cursores SQLite manualmente ao construir funcionalidades do produto, todo o motor foi encapsulado em quatro primitivas reativas de alto nível expostas pelo deltadb::Client:

  • Register<T>: contêiner escalar com resolução last-writer-wins;
  • Map<K, V>: dicionário distribuído com semântica add-wins;
  • Buffer: texto colaborativo apoiado em rope e índice de fragmentos por caractere;
  • Worktree: árvore de arquivos sobreposta ao Git que começa em um commit base e mantém cada arquivo fixado no blob original ou acrescido dos deltas escritos desde então.

Com a macro procedural #[derive(Replicate)], estruturas complexas do domínio da aplicação são declaradas como código Rust idiomático:

#[derive(Clone, Replicate)]
struct Thread {
    #[field(0)] transcript: Buffer,
    #[field(1)] name: Register<String>,
    #[field(2)] worktree: Worktree,
    #[field(3)] comments: Map<u64, Comment>,
}

Por trás dessa ergonomia, cada Register, Map, Buffer ou Worktree é apenas um ponteiro leve (RegisterId, BufferId) para dentro de um único CRDT plano chamado Snapshot, composto por quatro árvores B+ Copy-on-Write (CowBTree).

A macro #[derive(Replicate)] transforma structs Rust em ponteiros tipados para um Snapshot plano composto por árvores B+ Copy-on-Write.

Concorrência entre Main Thread e Background sem travar a UI

Enquanto na CLI do Delta o processo pode consultar o SQLite diretamente, na interface gráfica nativa do Delta (construída sobre a fundação acelerada por GPU do Zed) qualquer operação de I/O bloqueante na main thread estouraria imediatamente o orçamento estrito de 8 milissegundos por quadro (120 fps).

A solução engenhada pela equipe trata a própria main thread da UI e as threads de persistência em segundo plano como dois clientes concorrentes operando sobre o mesmo CRDT:

  1. Na abertura inicial, a main thread recebe uma versão alocada em Arc<Snapshot> na memória RAM;
  2. Quando o usuário digita ou interage com a interface, a main thread cunha novos deltas sincronamente em memória (zero I/O) e despacha esses deltas junto com um clone barato do Arc<Snapshot> (graças ao Copy-on-Write) para um pool em segundo plano (1 writer thread dedicada ao SQLite e 2 a 4 reader threads para rede);
  3. Assim que a writer thread grava a transação no SQLite, uma reader thread envia os novos deltas pelo WebSocket sem bloquear o escritor;
  4. Quando deltas remotos chegam da rede, o background aplica-os tanto ao snapshot do banco quanto ao snapshot da UI e devolve um novo Arc<Snapshot> atualizado para a main thread, reaplicando por cima eventuais deltas que o usuário tenha produzido naqueles poucos milissegundos.

Integração imediata: Delta CLI e plugin para Claude Code

Um dos aspectos mais pragmáticos do anúncio é que o DeltaDB não exige trocar de ferramenta da noite para o dia. Além do aplicativo desktop nativo Delta e da visualização em tempo real pelo navegador web, a Zed disponibilizou a Delta CLI e plugins oficiais para harnesses de terceiros — começando pelo Claude Code.

Dentro de qualquer sessão do Claude Code, basta adicionar o marketplace da Zed e instalar a extensão:

claude plugin marketplace add zed-industries/delta-claude
claude plugin install delta@zed-industries

A partir desse momento, executar /delta share dentro do Claude Code transforma a sessão local e sua worktree em uma thread sincronizada pelo DeltaDB: colegas de equipe podem entrar na mesma conversa pelo terminal ou pelo navegador, inspecionar os arquivos modificados enquanto o agente ainda está trabalhando, deixar comentários em linhas específicas e voltar no tempo para qualquer mensagem da conversa restaurando instantaneamente o estado exato dos arquivos no disco — sem precisar de um único git commit até que o trabalho esteja pronto para virar Pull Request.