Em 30 de outubro de 2026, no ES Databricks User Group, exploramos uma questão que vem ganhando espaço nas arquiteturas de dados: como aproximar o banco transacional dos aplicativos, da análise e dos agentes de IA sem transformar cada integração em mais um pipeline para operar?
O tema do encontro foi o Lakebase, o Postgres serverless da Databricks. A conversa partiu de uma ideia simples: dados operacionais continuam essenciais, mas não precisam permanecer isolados do lakehouse. Quando transação, análise, governança e desenvolvimento trabalham com contextos separados, surgem cópias, sincronizações frágeis e ambientes de teste caros de manter.
Em muitas organizações, o banco que atende ao ERP, ao CRM ou ao aplicativo está de um lado; o lakehouse, o BI e os modelos de IA estão de outro. Para conectá-los, criamos fluxos de ETL para levar dados operacionais à camada analítica e reverse ETL para devolver resultados aos sistemas.
Esse padrão funciona, mas cobra seu preço:
O Lakebase propõe reduzir essa distância. Ele é voltado para cargas transacionais — ou OLTP — e usa PostgreSQL como interface de banco, mas foi desenhado para operar próximo ao lakehouse.
A ideia central do Lakebase é separar compute e storage. O compute executa o Postgres e atende às conexões; os dados e o log de transações ficam em uma camada de armazenamento desacoplada e durável.
Essa separação tem consequências práticas importantes. Um compute pode ser suspenso sem que os dados desapareçam. A capacidade de processamento pode crescer de acordo com a demanda. E, principalmente, criar uma cópia lógica do banco deixa de significar copiar todos os arquivos físicos.
É por isso que o Lakebase torna possível falar em banco de dados como infraestrutura efêmera: um banco para uma tarefa, uma branch de código, um pull request ou um agente pode existir apenas enquanto for necessário.
O recurso que mais muda o fluxo de desenvolvimento é o branching. Uma branch do Lakebase nasce a partir de outra em menos de um segundo, independentemente do tamanho do banco, porque começa compartilhando os dados da origem. À medida que recebe alterações, grava apenas as páginas que mudaram — um modelo conhecido como copy-on-write.
Na prática, isso permite um fluxo muito próximo ao que já fazemos com Git:
Vale uma distinção importante: o schema diff ajuda a revisar o que mudou no schema, mas não promove uma alteração automaticamente. A promoção continua sendo responsabilidade da migration e do processo de deploy. Essa é uma boa separação de responsabilidades: a branch dá isolamento e velocidade; a migration mantém a mudança explícita, revisável e reproduzível.
Também é possível criar uma branch a partir de um ponto no tempo. Para incidentes operacionais, isso oferece uma alternativa interessante: em vez de restaurar uma cópia completa para investigar um DELETE indevido, cria-se uma branch a partir do instante anterior ao problema e compara-se o resultado com segurança.
Agentes de código não deveriam experimentar diretamente em produção. Eles precisam de um ambiente isolado, descartável e próximo do cenário real para criar uma tabela, testar uma migration, validar uma tela ou executar uma suíte de testes.
No webinar, demonstramos esse cenário com o MicroERP da DEX. Ao abrir uma worktree para construir um dashboard de contas a receber, um hook cria uma branch específica do Lakebase. O agente pode criar uma view ou um índice, executar a aplicação e gerar um pull request sem interferir na branch de produção.
O valor não está apenas em “dar um banco ao agente”. Está em incluir o banco no mesmo ciclo de engenharia do código:
Este padrão também funciona para desenvolvedores humanos. O ponto é reduzir o atrito de testar uma mudança real sem transformar todo experimento em uma solicitação manual de infraestrutura.
O Lakebase oferece escala vertical por Compute Units (CUs). É possível definir uma faixa de autoscaling para que o compute cresça em períodos de demanda e reduza quando a carga diminui. Para configurações compatíveis, o scale to zero suspende o compute ocioso e uma nova conexão o reativa.
Para cargas predominantemente de leitura, há também réplicas de leitura. Elas permitem separar consultas de relatórios, agentes e aplicações de leitura das escritas que seguem para o primário. Como qualquer arquitetura com replicação assíncrona, é preciso considerar a possibilidade de uma pequena defasagem nas leituras.
Na demonstração, o MicroERP usava um compute pequeno, de 0,5 CU, configurado para suspender após cinco minutos sem uso. Isso é adequado a um ambiente de demonstração; o dimensionamento de produção deve considerar concorrência, latência, perfil de consulta, requisitos de disponibilidade e custos da nuvem e região escolhidas.
O Lakebase não substitui o lakehouse para análises pesadas. A proposta é dar ao aplicativo uma camada transacional e conectá-la a uma plataforma analítica governada. Durante o encontro, destacamos três formas de fazer essa ponte:
A terceira alternativa foi o destaque da demo. Ao registrar o banco no Unity Catalog, suas tabelas passam a aparecer ao lado dos ativos Delta para SQL Warehouses, notebooks, dashboards e experiências como Genie. Isso permite, por exemplo, consultar uma tabela operacional de contas a receber e combiná-la com uma tabela Delta em uma mesma consulta.
O app continua escrevendo diretamente no Postgres. Já a consulta analítica é executada pelo SQL Warehouse, com os controles e a visibilidade oferecidos pelo Unity Catalog. É uma divisão saudável: o banco atende à transação; o warehouse atende à análise.
Esse arranjo se aproxima do que o mercado chama de arquitetura translytical: a operação do aplicativo e a análise trabalham sobre dados próximos, sem exigir uma cadeia de cópias para cada pergunta de negócio.
No MicroERP, o desenho ficou assim:
Uma observação interessante da demonstração foi ver o compute do Lakebase suspenso enquanto o Genie respondia a uma pergunta sobre valores em atraso. A análise ocorreu pelo SQL Warehouse sobre o catálogo registrado; o banco do aplicativo não precisou permanecer ativo apenas para atender à consulta analítica.
O Lakebase é especialmente interessante quando há um ou mais destes cenários:
Mas a adoção precisa ser criteriosa. O produto é recente e o status de disponibilidade, as versões suportadas, as extensões e os limites variam por nuvem e região. Recursos específicos podem estar em preview. Avalie também o perfil da carga: análise pesada continua sendo uma responsabilidade natural do SQL Warehouse, e não do Postgres transacional.
Uma boa primeira iniciativa não precisa migrar o banco mais crítico da empresa. Vale escolher um aplicativo ou um caso de uso com escopo claro, perguntas conhecidas e uma equipe responsável pelo domínio.
Um piloto pode seguir este roteiro:
O Lakebase não elimina as decisões de arquitetura. Ele torna algumas delas mais simples: criar ambientes isolados, separar transação de análise, reduzir cópias e aproximar a governança do banco operacional à governança do restante dos dados.
O principal aprendizado do webinar foi que o banco transacional pode deixar de ser um componente isolado da estratégia de dados. Ao combinar Postgres serverless, branches, Databricks Apps, Unity Catalog e SQL Warehouses, torna-se possível oferecer experiências operacionais e analíticas com menos atrito entre quem cria, quem governa e quem usa os dados.
Para equipes que estão adotando agentes, talvez a mensagem mais prática seja esta: autonomia não é liberar produção para um agente. É disponibilizar ambientes isolados, com dados e regras adequados, para que pessoas e agentes possam testar, revisar e entregar com segurança.
