Há cinco anos, a Databricks cunhou o termo “knowledge lakehouse” para descrever um novo tipo de arquitetura de dados que combina um knowledge lake com um knowledge warehouse. Esse termo e arquitetura de dados agora são comuns em todo o setor de dados para cargas de trabalho analíticas.
Agora, a Databricks está mais uma vez procurando criar uma nova categoria com seu serviço Lakebase, agora disponível ao público em geral. Enquanto a construção do knowledge lakehouse lida com bancos de dados OLAP (processamento analítico on-line), Lakebase trata de OLTP (processamento de transações on-line) e bancos de dados operacionais. O serviço Lakebase está em desenvolvimento desde junho de 2025 e é baseado na tecnologia Databricks obtida por meio da aquisição de Provedor de banco de dados PostgreSQL Neon. Foi aprimorado ainda mais em outubro de 2025 com o aquisição da Mooncake, que trouxe recursos para ajudar a unir o PostgreSQL com formatos de dados lakehouse.
Lakebase é um banco de dados operacional sem servidor que representa uma reformulação elementary de como os bancos de dados funcionam na period dos agentes autônomos de IA. Os primeiros adotantes, incluindo easyJet, Hafnia e Warner Music Group, estão reduzindo os tempos de entrega de aplicativos em 75 a 95%, mas a inovação arquitetônica mais profunda posiciona os bancos de dados como infraestrutura efêmera e de autoatendimento que os agentes de IA podem provisionar e gerenciar sem intervenção humana.
Este não é apenas mais um serviço gerenciado do Postgres. Lakebase trata os bancos de dados operacionais como computação leve e descartável executada em armazenamento de knowledge lake, em vez de sistemas monolíticos que exigem planejamento cuidadoso de capacidade e supervisão do administrador de banco de dados (DBA).
“Realmente, para que a tendência de codificação de vibração decole, você precisa que os desenvolvedores acreditem que podem realmente criar novos aplicativos muito rapidamente, mas também precisa que a equipe central de TI, ou DBAs, se sinta confortável com o tsunami de aplicativos e bancos de dados”, disse o cofundador da Databricks, Reynold Xin, ao VentureBeat. “Os bancos de dados clássicos simplesmente não serão dimensionados para isso porque não podem se dar ao luxo de colocar um DBA por banco de dados e por aplicativo.”
Entrega 92% mais rápida: de dois meses a cinco dias
Os números de produção demonstram impacto imediato além da visão de provisionamento de agentes. A Hafnia reduziu o tempo de entrega de aplicativos prontos para produção de dois meses para cinco dias — ou 92% — usando Lakebase como mecanismo transacional para seu portal de operações internas. A empresa de transporte marítimo foi além dos relatórios estáticos de BI para aplicações de negócios em tempo actual para fluxos de trabalho de frota, comerciais e financeiros.
A EasyJet consolidou mais de 100 repositórios Git em apenas dois e reduziu os ciclos de desenvolvimento de nove para quatro meses – uma redução de 56% – ao mesmo tempo que construiu um centro de gestão de receitas baseado na Internet em Lakebase para substituir uma aplicação de desktop com uma década de existência e um dos maiores ambientes SQL Server legados da Europa.
O Warner Music Group está transferindo insights diretamente para os sistemas de produção usando a base unificada, enquanto o Quantum Capital Group a utiliza para manter dados consistentes e controlados para identificar e avaliar investimentos em petróleo e gás – eliminando a duplicação de dados que anteriormente forçava as equipes a manter múltiplas cópias em diferentes formatos.
A aceleração decorre da eliminação de dois grandes gargalos: clonagem de banco de dados para ambientes de teste e manutenção de pipeline ETL para sincronização de dados operacionais e analíticos.
Arquitetura técnica: por que isso não é apenas Postgres gerenciado
Os bancos de dados tradicionais combinam armazenamento e computação – as organizações fornecem uma instância de banco de dados com armazenamento e escala anexados, adicionando mais instâncias ou armazenamento. O AWS Aurora inovou ao separar essas camadas usando armazenamento proprietário, mas o armazenamento permaneceu bloqueado dentro do ecossistema da AWS e não period acessível de forma independente para análise.
Lakebase leva a separação entre armazenamento e computação à sua conclusão lógica, colocando o armazenamento diretamente no knowledge lakehouse. A camada de computação executa essencialmente PostgreSQL básico – mantendo whole compatibilidade com o ecossistema Postgres – mas cada gravação vai para o armazenamento lakehouse em formatos que Spark, Databricks SQL e outros mecanismos de análise podem consultar imediatamente sem ETL.
“O perception técnico único foi que os knowledge lakes separam o armazenamento da computação, o que foi ótimo, mas precisamos introduzir recursos de gerenciamento de dados, como governança e gerenciamento de transações, no knowledge lake”, explicou Xin. “Na verdade, não somos tão diferentes do conceito de lakehouse, mas estamos construindo uma computação leve e efêmera para bancos de dados OLTP.”
A Databricks construiu o Lakebase com a tecnologia obtida com a aquisição da Neon. Mas Xin enfatizou que o Databricks expandiu significativamente as capacidades originais do Neon para criar algo fundamentalmente diferente.
“Eles não tinham experiência empresarial e não tinham escala de nuvem”, disse Xin. “Reunimos a nova ideia arquitetônica da equipe Neon com a robustez da infraestrutura do Databricks e as combinamos. Agora criamos uma plataforma superescalável.”
De centenas de bancos de dados a milhões criados para IA de agência
Xin delineou uma visão diretamente ligada à economia das ferramentas de codificação de IA que explica por que a construção Lakebase é importante além dos casos de uso atuais. À medida que os custos de desenvolvimento despencam, as empresas deixarão de comprar centenas de aplicações SaaS e passarão a construir milhões de aplicações internas personalizadas.
“À medida que o custo do desenvolvimento de software program diminui, o que estamos vendo hoje por causa das ferramentas de codificação de IA, isso mudará da proliferação de SaaS nos últimos 10 a 15 anos para a proliferação do desenvolvimento interno de aplicativos”, disse Xin. “Em vez de criar talvez centenas de aplicativos, eles criarão milhões de aplicativos personalizados ao longo do tempo”.
Isto cria um problema impossível de gestão de frota com abordagens tradicionais. Você não pode contratar DBAs suficientes para provisionar, monitorar e solucionar problemas manualmente de milhares de bancos de dados. A solução de Xin: trate o próprio gerenciamento de banco de dados como um problema de dados, e não como um problema operacional.
Lakebase armazena toda a telemetria e metadados – desempenho de consulta, utilização de recursos, padrões de conexão, taxas de erro – diretamente no lakehouse, onde podem ser analisados usando ferramentas padrão de engenharia de dados e ciência de dados. Em vez de configurar painéis em ferramentas de monitoramento específicas de banco de dados, as equipes de dados consultam dados de telemetria com SQL ou analisam-nos com modelos de aprendizado de máquina para identificar discrepâncias e prever problemas.
“Em vez de criar um painel para cada 50 ou 100 bancos de dados, você pode realmente olhar o gráfico para entender se algo se comportou mal”, explicou Xin. “O gerenciamento de banco de dados será muito semelhante a um problema de análise. Você observa valores discrepantes, observa tendências, tenta entender por que as coisas acontecem. É assim que você gerencia em escala quando os agentes estão criando e destruindo bancos de dados programaticamente.”
As implicações estendem-se aos próprios agentes autónomos. Um agente de IA com problemas de desempenho poderia consultar os dados de telemetria para diagnosticar problemas — tratando as operações de banco de dados como apenas mais uma tarefa analítica, em vez de exigir conhecimento especializado de DBA. O gerenciamento de banco de dados torna-se algo que os agentes podem fazer por si próprios, usando os mesmos recursos de análise de dados que já possuem.
O que isso significa para as equipes de dados empresariais
A construção Lakebase sinaliza uma mudança elementary na forma como as empresas devem pensar sobre os bancos de dados operacionais – não como uma infraestrutura preciosa e cuidadosamente gerenciada que requer DBAs especializados, mas como recursos efêmeros e de autoatendimento que escalam programaticamente como a computação em nuvem.
Isto é importante quer os agentes autónomos se materializem ou não tão rapidamente como o Databricks prevê, porque o princípio arquitetónico subjacente – tratar a gestão de bases de dados como um problema analítico em vez de um problema operacional – altera os conjuntos de competências e as estruturas de equipa de que as empresas necessitam.
Os líderes de dados devem prestar atenção à convergência de dados operacionais e analíticos que ocorre em todo o setor. Quando as gravações em um banco de dados operacional podem ser consultadas imediatamente por mecanismos de análise sem ETL, as fronteiras tradicionais entre sistemas transacionais e knowledge warehouses ficam confusas. Essa arquitetura unificada reduz a sobrecarga operacional da manutenção de sistemas separados, mas também exige repensar as estruturas das equipes de dados construídas em torno desses limites.
Quando o lakehouse foi lançado, os concorrentes rejeitaram o conceito antes de adotá-lo eles próprios. Xin espera a mesma trajetória para Lakebase.
“Faz sentido separar o armazenamento e a computação e colocar todo o armazenamento no lago – isso permite muitos recursos e possibilidades”, disse ele.
