Databricks detalha o branching do Lakebase para agentes de codificação paralelos

Databricks, em 8 de outubro de 2026, publicou uma postagem de blog detalhando um fluxo de desenvolvimento no qual cada agente de codificação paralela e cada pull request são executados em seu próprio banco de dados Postgres isolado e efêmero, criado por meio do branching copy-on-write incorporado ao seu serviço de banco de dados Lakebase.

No post, a Databricks descreve o banco de dados como uma parte frequentemente negligenciada do fluxo de desenvolvimento em um momento em que os agentes de codificação estão assumindo uma parcela crescente do trabalho de desenvolvimento e a execução de múltiplos agentes em paralelo está se tornando a norma. Em ambientes compartilhados tradicionais, como um único banco de dados de desenvolvimento ou de staging, agentes concorrentes podem entrar em conflito nas alterações de esquema, interferir uns com os outros ou recorrer a mocks que não refletem dados do mundo real. Esses já eram pontos críticos para os desenvolvedores, afirma o post, mas os agentes os agravam porque se movem mais rápido, operam em paralelo e precisam de um ambiente seguro que evite colocar dados de produção em risco ou expor dados sensíveis.

Mecânica de ramificação

A Databricks afirma que o branching do Lakebase permite que um usuário crie um branch de um banco de dados inteiro em menos de um segundo, independentemente de seu tamanho. Os branches dependem de armazenamento copy-on-write: um novo branch herda o esquema e os dados de seu pai enquanto compartilha o armazenamento subjacente, consumindo armazenamento adicional apenas à medida que diverge. De acordo com documentação de branching do Lakebase da Databricks, cada projeto é criado com um branch padrão chamado production, e todo branch, exceto o branch raiz, possui um pai. Alterações em um branch filho nunca afetam seu pai, e o isolamento se estende ao estado de papéis do Postgres: papéis e bancos de dados criados, GRANTs e REVOKEs aplicados, e atributos de papéis modificados em um branch não têm efeito em outros branches.

Cada branch possui seu próprio compute, escala para zero quando está ocioso e é cobrado apenas pelas horas de compute ativas, afirma a documentação. A cobrança de armazenamento depende de o branch expirar ou não: um branch que expira é cobrado apenas pelos dados alterados nele, enquanto um branch permanente sem expiração é cobrado pelo tamanho total de seus dados, como um banco de dados independente. Um reset de branch, que atualiza um branch filho a partir de seu pai, funciona em apenas uma direção, do pai para o filho. A recuperação pontual cria um novo branch raiz a partir de dados históricos dentro da janela de restauração, mantendo o branch original inalterado e operacional.

Na sua página de produto, a Databricks descreve o Lakebase como um serviço Postgres totalmente gerenciado e serverless que executa o mecanismo Postgres de código aberto em vez de um fork.

Um branch por agente

O fluxo de trabalho no post combina worktrees do Git com branches do Lakebase. Um worktree fornece a cada agente seu próprio diretório com seu próprio branch verificado, eliminando conflitos a nível de arquivo entre agentes, e um hook pós-checkout cria automaticamente um branch de banco de dados para cada novo worktree. No exemplo, construído com Claude Code, um agente executa claude -worktree feature-123, o Git cria o worktree, o hook é disparado, e o agente termina com seu próprio diretório de código e seu próprio banco de dados totalmente isolado. Arquivos de instrução do repositório, como AGENTS.md ou CLAUDE.md, orientam o comportamento do agente, e quando o agente termina ele abre um pull request, após o qual tanto o worktree quanto o branch do banco de dados podem ser desativados.

Uma diferença em relação ao Git, observa o post, é que os branches do Lakebase não são mesclados de volta ao branch principal, porque pai e filho podem mudar independentemente e reconciliar seus dados pode rapidamente se tornar impraticável. Em vez disso, alterações de esquema são rastreadas no código junto com a lógica da aplicação e promovidas ao branch pai por meio de migrações, usando ferramentas como Drizzle, Flyway, Liquibase ou Alembic. O exemplo usa o Drizzle: quando uma alteração de esquema é necessária, o agente adiciona a migração correspondente ao código, e a automação de implantação a aplica ao implantar a aplicação de pré-visualização e novamente quando a alteração é mesclada ao main.

Um branch por Pull Request

Para integração contínua, o post descreve um fluxo de trabalho do GitHub Actions no qual a abertura de um pull request contra o main aciona o Lakebase CLI para criar um branch efêmero, nomeado a partir do pull request, como filho do branch production, e esse branch se torna o ambiente de banco de dados do pull request. A ferramenta de migração é executada contra o novo branch, uma aplicação de pré-visualização é implantada e apontada para a string de conexão do branch, e um diff de esquema é gerado e publicado como um comentário de pull-request mostrando exatamente quais tabelas, colunas ou índices foram alterados. Quando o pull request é fechado ou mesclado, a automação exclui o branch. Como o branch parte da produção, a migração de esquema pode ser aplicada e testada antes que a alteração chegue à produção. O exemplo implanta pré-visualizações no Databricks Apps, embora o post afirme que o conceito se aplica a outras plataformas de hospedagem, como Vercel, Netlify e Cloudflare.

Nos ambientes, o post observa que uma configuração comum do Lakebase usa um workspace da Databricks por ambiente, como desenvolvimento, staging e produção, e que as equipes costumam criar branches a partir de um banco de dados semeado em vez do banco de dados de produção para evitar expor dados sensíveis, como PII. O tutorial usa um único workspace por simplicidade, ao mesmo tempo que observa que os mesmos conceitos se aplicam a configurações com múltiplos workspaces.

Reprodução de Bugs e Teste de Migrações

Além dos loops por agente e por pull request, o post descreve fluxos de trabalho de ramificação que não são implementados no repositório de exemplo. Um desenvolvedor pode criar um branch isolado a partir da produção em um ponto específico no tempo, tipicamente pouco antes de um bug aparecer, reproduzir e investigar o problema com dados reais, e encerrar o branch depois que uma correção for validada. As equipes também podem criar um branch antes de implantar em produção, aplicar uma migração de esquema, executar testes e verificar se a aplicação ainda se comporta como esperado antes de promover a alteração. Esses fluxos de trabalho permitem que os desenvolvedores trabalhem com dados semelhantes aos de produção ou derivados da produção, usando, por exemplo, mascaramento do Unity Catalog, sem colocar o banco de dados ao vivo em risco, afirma o post.

O post vincula a um repositório de exemplo no GitHub, no diretório Lakebase-Agentic-CI do repositório databricks/tmm, que contém exemplos de fluxos de trabalho do GitHub Actions implementando o padrão. Conclui que, juntos, esses padrões formam o que ele chama de loop de desenvolvimento Lakebase: um branch por agente, um branch por pull request e branches isolados para validação em produção.