Ramificação de Banco de Dados no Postgres: Fluxos de Trabalho Estilo Git com Databricks Lakebase

O banco de dados é o último gargalo no seu fluxo de trabalho de desenvolvimento

O branching de banco de dados é a primitiva que falta nos fluxos de trabalho de desenvolvimento modernos. Todas as outras partes da stack evoluíram para suportar iteração rápida. Código tem Git. Infraestrutura tem Terraform. Deployments têm pipelines de CI/CD que rodam em minutos. Mas bancos de dados relacionais ainda funcionam como há dez anos.

A maioria das equipes compartilha um único banco de dados de staging. Em poucos dias após a configuração, esse banco de dados sai de sincronia com a produção. Schemas divergem à medida que desenvolvedores aplicam migrações em ordens diferentes. Valores de sequência não correspondem mais. Dados de teste se acumulam e poluem os resultados. Alguém eventualmente reseta tudo, e o ciclo recomeça.

Configurar um novo ambiente é pior. A abordagem padrão é rodar pg_dump contra a produção, esperar terminar (minutos a horas dependendo do tamanho do banco de dados), carregar em uma nova instância, configurar acesso e torcer para que o resultado realmente reflita o que está rodando em produção. Para um banco de dados de 500GB, isso significa uma operação de cópia de 500GB, mais o compute e armazenamento para mantê-lo rodando.

O resultado é previsível. Equipes evitam criar novos ambientes porque são muito caros e lentos. Desenvolvedores compartilham um único banco de dados de staging mutável. Migrações são testadas contra dados desatualizados, ou não são testadas. Deployments de preview rodam contra fixtures vazias em vez de schemas realistas. Testes de CI compartilham estado e produzem resultados instáveis.

O banco de dados se torna a parte da stack que os desenvolvedores têm medo de tocar.

Databricks Lakebase Postgres muda isso com branching de banco de dados.

O que é realmente o branching de banco de dados

Um branch de banco de dados não é uma cópia de banco de dados. Essa distinção importa porque muda a economia de ambientes isolados completamente.

Quando você copia um banco de dados, você duplica todos os seus dados e schema em uma nova instância independente. O tempo e o custo escalam linearmente com o tamanho do banco de dados. Cada cópia é um clone completo, e cada clone começa a ficar desatualizado no momento em que é criado.

Um branch funciona de forma diferente. Quando você cria um branch no Lakebase, você obtém um novo ambiente Postgres totalmente isolado que:

• Começa com o schema e dados exatos de seu pai em um ponto específico no tempo
• Compartilha o mesmo armazenamento subjacente em vez de duplicá-lo
• Só escreve novos dados quando você realmente faz alterações

Isso é chamado de copy-on-write. Enquanto dois branches não divergirem, eles referenciam os mesmos dados armazenados. Quando você roda uma migração, insere linhas, ou modifica tabelas em um branch, apenas essas alterações são escritas separadamente. Todo o resto é compartilhado com o pai.

Cópia de banco de dados vs. branch de banco de dados

Em termos práticos, isso significa:

• A criação de branch leva segundos, independentemente do tamanho do banco de dados. Um banco de dados de 10GB e um de 2TB criam branch no mesmo tempo.
• O custo de armazenamento é proporcional às alterações, não ao tamanho total dos dados. Um branch que modifica 50MB de dados em um banco de dados de 500GB usa aproximadamente 50MB de armazenamento adicional.
• Cada branch obtém sua própria string de conexão Postgres e endpoint de compute. Branches são totalmente isolados uns dos outros e de seu pai.
• Branches ociosos escalam automaticamente o compute para zero. Você paga apenas pelo compute ativo quando um branch está sendo realmente usado.

Branches são projetados para serem criados, usados e descartados livremente. Por desenvolvedores, por pipelines de CI, por agentes de IA, por automação. Eles não são ambientes preciosos que precisam ser mantidos. Eles são descartáveis, como branches Git.

A arquitetura que torna o branching de banco de dados possível

O Postgres gerenciado tradicional (RDS, Azure Database for PostgreSQL) une compute e armazenamento. O processo do banco de dados e seus dados vivem na mesma instância, e os dados são armazenados como um único sistema de arquivos mutável. É por isso que a cópia é a única opção para criar um segundo ambiente: você tem que duplicar o sistema de arquivos.

Mas um lakebase é construído de forma diferente. Ele separa completamente compute de armazenamento. Todos os dados são escritos em um motor de armazenamento distribuído e versionado que registra cada alteração como uma nova versão em vez de sobrescrever os dados existentes. Essa arquitetura log-structured é o que torna o branching de banco de dados possível como uma primitiva em vez de um recurso sobreposto.

Como o armazenamento é versionado, múltiplos branches podem referenciar os mesmos dados subjacentes sem risco de conflito. Como o compute é independente, cada branch roda seu próprio processo Postgres e escala por conta própria. Branches não produtivos que ficam ociosos escalam para zero automaticamente e reiniciam em milissegundos quando uma conexão chega.

Nem todas as implementações de branching de banco de dados são iguais. Algumas plataformas criam cópias completas de instância e as chamam de branches. Outras fazem branch apenas do schema, sem dados. Branches do Lakebase incluem schema e dados, usam copy-on-write na camada de armazenamento para evitar duplicação, e fornecem compute independente e autoescalável por branch. Isso é o que torna prático criar branches livremente e em escala, sem provisionar infraestrutura adicional.

Essa arquitetura também habilita o time travel. Como cada versão dos dados é retida dentro de uma janela de restauração configurável, você pode criar um branch de qualquer ponto do passado, não apenas do estado atual. Isso é o que impulsiona a recuperação instantânea point-in-time: em vez de reexecutar logs WAL ou restaurar um backup, você cria um branch no timestamp que precisa e lê diretamente dele.

O que o branching de banco de dados desbloqueia para sua equipe

Uma vez que o branching de banco de dados se torna uma primitiva rápida e barata em vez de uma operação de cópia cara, novos fluxos de trabalho se tornam práticos. Aqui está um resumo dos padrões mais comuns. (Cobrimos cada um deles em detalhes na próxima postagem desta série.)

Um branch por desenvolvedor. Cada engenheiro obtém seu próprio ambiente isolado com dados semelhantes aos de produção. Chega de pisar nas alterações uns dos outros em um banco de dados de desenvolvimento compartilhado. Quando um branch se desvia muito da produção, resete-o em um comando para puxar o schema e os dados mais recentes. Como os branches escalam para zero quando ociosos, esse padrão permanece acessível mesmo em equipes grandes.

Um branch por pull request. Automatize a criação de branch quando um PR abre e a exclusão quando ele é mesclado ou fechado. Deployments de preview no Vercel ou Netlify recebem seu próprio branch de banco de dados, então seu preview frontend é suportado por dados realistas e isolados. Migrações rodam contra formas e restrições de dados reais, não fixtures de teste vazias. Este é o fluxo de trabalho que as equipes adotam primeiro, e tende a ser o que as convence a adotar o branching de banco de dados em geral.

Um branch por execução de teste. Pipelines de CI obtêm um banco de dados fresco e isolado para cada execução. Sem estado residual de testes anteriores. Sem esperar que uma imagem de container vazia inicie e depois seja preenchida com dados falsos. Sem resultados instáveis causados por dados compartilhados ou dependências de ordem de teste. Cada execução começa da mesma linha de base. Para testes que exigem dados determinísticos, você pode criar branches de um ponto fixo no tempo ou de um Log Sequence Number (LSN) específico.

Recuperação instantânea. Crie um branch a partir de qualquer ponto no tempo dentro da sua janela de restauração. Inspecione tabelas descartadas, depure migrações com falha ou audite dados históricos, tudo sem tocar na produção. Use a comparação de esquemas para comparar o estado antes e depois de uma alteração. Exporte o que você precisa do branch de recuperação e, em seguida, exclua-o. Todo o processo leva segundos, não as horas ou dias que o PITR tradicional exige.

Ambientes efêmeros para agentes de IA. Agentes de IA podem provisionar bancos de dados programaticamente via Lakebase API, usá-los pela duração de uma tarefa e desligá-los quando terminarem. Plataformas podem construir versionamento sobre snapshots: cada ação do agente cria um checkpoint, e os usuários podem pular entre versões instantaneamente. Se um agente executar uma migração ruim ou corromper dados, reverter é uma única chamada de API.

Começando

O branching de banco de dados no Databricks Lakebase transforma seu banco de dados Postgres da parte mais lenta do seu fluxo de trabalho de desenvolvimento na mais rápida.

Você pode criar seu primeiro branch em menos de um minuto usando o console, CLI ou API. Veja como é a partir da CLI:

É isso. Agora você tem um ambiente Postgres isolado com o esquema e dados completos da produção, pronto para usar.

Se você está desenvolvendo em Postgres e cansado da sobrecarga que vem com o gerenciamento de ambientes de banco de dados, comece com um único branch de desenvolvimento. Em seguida, experimente um por PR. A maioria das equipes que começam com um fluxo de trabalho de branching de banco de dados rapidamente adotam o restante.

Databricks Lakebase é Postgres serverless construído para agentes e aplicativos. Saiba mais em databricks.com/product/lakebase.

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original