Por décadas, as organizações mantiveram dois mundos separados para seus dados. Os sistemas de Processamento Transacional Online (OLTP) cuidam das operações do dia a dia — pedidos, atualizações de inventário, cadastros de clientes — enquanto os sistemas de Processamento Analítico Online (OLAP) executam relatórios, dashboards e treinamento de modelos. Mover dados entre eles exige processos de extração, transformação e carga (ETL, na sigla em inglês), que geram latência, custos e enormes dores de cabeça com governança.

O LTAP visa unificar essas cargas de trabalho em uma única cópia dos dados armazenados no data lake. Segundo a Databricks, a arquitetura elimina a necessidade de ETL, réplicas de dados e movimentação de dados por definição . Os dados transacionais tornam-se disponíveis para análises de forma instantânea, sem transformações ou manutenção de pipelines.

A base do LTAP é o Lakebase, o serviço serverless de Postgres da Databricks construído sobre armazenamento de objetos abertos. O Lakebase já atende milhares de clientes e gerencia 12 milhões de inicializações de banco de dados por dia em toda a plataforma . Dentro do modelo LTAP, o Lakebase armazena os dados diretamente no Unity Catalog em formatos abertos — Delta Lake e Apache Iceberg — para que os dados transacionais governados possam ser consultados imediatamente para cargas de trabalho analíticas .

A empresa descreve várias propriedades-chave para a arquitetura: governança unificada com uma única fonte de verdade, dimensionamento independente para cargas transacionais e analíticas, semântica ACID completa para cargas de trabalho em Postgres, e nenhum pipeline ou conector oculto para manter .

Novas capacidades do Lakebase

Junto com o anúncio do LTAP, a Databricks revelou várias melhorias para o próprio Lakebase:

• Recuperação de desastres entre nuvens e regiões para bancos de dados de produção em Postgres.
• Ramificações e snapshots no estilo Git, permitindo experimentações seguras diretamente sobre os dados de produção.
• Operações autônomas de banco de dados que monitoram lentidões, detectam anomalias e acionam recuperações automáticas .

Esses recursos sinalizam a intenção da Databricks de tornar o Postgres serverless um banco de dados operacional de primeira classe para aplicações e agentes de IA, não apenas uma camada de conveniência para análises.

Lakehouse//RT: análises em tempo real sobre dados governados

O segundo grande anúncio de infraestrutura foi o Lakehouse//RT, um lakehouse em tempo real alimentado por um novo motor de computação chamado Reyden (abreviação de “Reynold’s Dream Engine”, em homenagem ao cofundador Reynold Xin) . A Databricks afirma que o Reyden oferece consultas com latência de milissegundos para dezenas de milhares de usuários e agentes simultâneos, rodando diretamente sobre tabelas governadas no Delta Lake e Apache Iceberg .

A implicação é significativa: as empresas não precisam mais configurar infraestruturas de serviço separadas — como camadas de cache, visões materializadas ou motores de consulta externos — para alcançar desempenho em tempo real. A Sigma Computing foi anunciada como parceira de lançamento, conectando-se diretamente ao Lakehouse//RT para análises embarcadas .

O cofundador da Databricks, Reynold Xin, descreveu o lançamento como “provavelmente a maior introdução que fizemos desde o lançamento do Lakehouse” .

O avanço dos agentes: Genie One, Agent Bricks e ferramentas de IA

A Databricks aproveitou a conferência para posicionar sua plataforma como a base para agentes de IA corporativos. Os anúncios incluíram:

• Genie One: Um agente de IA autônomo projetado para ajudar equipes de negócios a automatizar o trabalho com base em dados reais da empresa, com melhorias para o contexto agentivo .
• Genie Agents e Agent Bricks: Ferramentas para construir e implantar agentes de IA que podem observar, raciocinar e agir sobre dados corporativos. Os Agent Bricks são componentes pré-construídos que otimizam automaticamente os agentes usando dados governados .
• Unity AI Gateway: Governança multi-IA e controle de custos para organizações que gerenciam múltiplos provedores de modelos de IA .

A narrativa mais ampla, capturada por analistas da indústria, é que o LTAP e o Lakehouse//RT são as camadas de serviço de dados que sustentam uma arquitetura corporativa “agentiva”. Ao colocar os dados operacionais em formatos abertos em um armazenamento governado, a Databricks acredita que os agentes de IA podem acessar, raciocinar e agir sobre bancos de dados de produção sem mover ou copiar dados .

Integrações com Azure e Microsoft

A Databricks aprofundou sua integração com o ecossistema Azure, anunciando várias capacidades em conjunto:

• Copilot Studio e GitHub Copilot: Os usuários podem criar agentes no Copilot Studio que raciocinam sobre todo um workspace do Azure Databricks por meio de uma única conexão MCP (Model-Centric-Protocol) .
• Genie para Microsoft Teams e M365 Copilot (Beta): Os usuários podem marcar o Genie em uma conversa no Teams e receber respostas contextuais diretamente do seu ambiente Azure Databricks .
• Suplemento do Azure Databricks para Excel (Pré-visualização Pública) e ingestão nativa de dados do Excel (disponível para todos) permitem análises autônomas a partir de planilhas .
• Databricks CustomerLake: A primeira plataforma de dados do cliente nativa do lakehouse, revelada para o Azure Databricks .

Essas integrações sugerem uma estratégia para embutir as capacidades de governança e IA da Databricks nas próprias ferramentas de colaboração onde as decisões de negócios acontecem, em vez de exigir que os usuários alternem para uma interface de análise separada.

O que isso significa para a arquitetura de dados corporativa

Em conjunto, os anúncios do summit representam uma aposta de plataforma coerente: a de que a próxima geração de aplicações empresariais será agentiva, em tempo real e governada. O LTAP remove a divisão entre transacional e analítico, o Lakehouse//RT elimina o compromisso com a latência para consultas analíticas, e a família Genie fornece a camada de orquestração dos agentes.

Se bem-sucedida, essa arquitetura pode reduzir o número de partes móveis em uma pilha de dados corporativa típica — menos bancos de dados, menos pipelines, menos camadas de serviço — enquanto fornece aos agentes de IA o contexto governado e em tempo real de que precisam para agir de forma autônoma sobre os dados de negócio.

A Databricks não está sozinha nessa corrida pela convergência, mas com o Lakebase já realizando 12 milhões de inicializações diárias de banco de dados e um evento de 30.000 participantes reforçando seu ecossistema, o anúncio do LTAP marca um marco significativo na evolução da arquitetura lakehouse, de uma plataforma de análise para uma espinha dorsal de dados operacionais .

Por décadas, as organizações mantiveram dois mundos separados para seus dados. Os sistemas de Processamento Transacional Online (OLTP) cuidam das operações do dia a dia — pedidos, atualizações de inventário, cadastros de clientes — enquanto os sistemas de Processamento Analítico Online (OLAP) executam relatórios, dashboards e treinamento de modelos. Mover dados entre eles exige processos de extração, transformação e carga (ETL, na sigla em inglês), que geram latência, custos e enormes dores de cabeça com governança.

O LTAP visa unificar essas cargas de trabalho em uma única cópia dos dados armazenados no data lake. Segundo a Databricks, a arquitetura elimina a necessidade de ETL, réplicas de dados e movimentação de dados por definição . Os dados transacionais tornam-se disponíveis para análises de forma instantânea, sem transformações ou manutenção de pipelines.

A base do LTAP é o Lakebase, o serviço serverless de Postgres da Databricks construído sobre armazenamento de objetos abertos. O Lakebase já atende milhares de clientes e gerencia 12 milhões de inicializações de banco de dados por dia em toda a plataforma . Dentro do modelo LTAP, o Lakebase armazena os dados diretamente no Unity Catalog em formatos abertos — Delta Lake e Apache Iceberg — para que os dados transacionais governados possam ser consultados imediatamente para cargas de trabalho analíticas .

A empresa descreve várias propriedades-chave para a arquitetura: governança unificada com uma única fonte de verdade, dimensionamento independente para cargas transacionais e analíticas, semântica ACID completa para cargas de trabalho em Postgres, e nenhum pipeline ou conector oculto para manter .

Novas capacidades do Lakebase

Junto com o anúncio do LTAP, a Databricks revelou várias melhorias para o próprio Lakebase:

• Recuperação de desastres entre nuvens e regiões para bancos de dados de produção em Postgres.
• Ramificações e snapshots no estilo Git, permitindo experimentações seguras diretamente sobre os dados de produção.
• Operações autônomas de banco de dados que monitoram lentidões, detectam anomalias e acionam recuperações automáticas .

Esses recursos sinalizam a intenção da Databricks de tornar o Postgres serverless um banco de dados operacional de primeira classe para aplicações e agentes de IA, não apenas uma camada de conveniência para análises.

Lakehouse//RT: análises em tempo real sobre dados governados

O segundo grande anúncio de infraestrutura foi o Lakehouse//RT, um lakehouse em tempo real alimentado por um novo motor de computação chamado Reyden (abreviação de “Reynold’s Dream Engine”, em homenagem ao cofundador Reynold Xin) . A Databricks afirma que o Reyden oferece consultas com latência de milissegundos para dezenas de milhares de usuários e agentes simultâneos, rodando diretamente sobre tabelas governadas no Delta Lake e Apache Iceberg .

A implicação é significativa: as empresas não precisam mais configurar infraestruturas de serviço separadas — como camadas de cache, visões materializadas ou motores de consulta externos — para alcançar desempenho em tempo real. A Sigma Computing foi anunciada como parceira de lançamento, conectando-se diretamente ao Lakehouse//RT para análises embarcadas .

O cofundador da Databricks, Reynold Xin, descreveu o lançamento como “provavelmente a maior introdução que fizemos desde o lançamento do Lakehouse” .

O avanço dos agentes: Genie One, Agent Bricks e ferramentas de IA

A Databricks aproveitou a conferência para posicionar sua plataforma como a base para agentes de IA corporativos. Os anúncios incluíram:

• Genie One: Um agente de IA autônomo projetado para ajudar equipes de negócios a automatizar o trabalho com base em dados reais da empresa, com melhorias para o contexto agentivo .
• Genie Agents e Agent Bricks: Ferramentas para construir e implantar agentes de IA que podem observar, raciocinar e agir sobre dados corporativos. Os Agent Bricks são componentes pré-construídos que otimizam automaticamente os agentes usando dados governados .
• Unity AI Gateway: Governança multi-IA e controle de custos para organizações que gerenciam múltiplos provedores de modelos de IA .

A narrativa mais ampla, capturada por analistas da indústria, é que o LTAP e o Lakehouse//RT são as camadas de serviço de dados que sustentam uma arquitetura corporativa “agentiva”. Ao colocar os dados operacionais em formatos abertos em um armazenamento governado, a Databricks acredita que os agentes de IA podem acessar, raciocinar e agir sobre bancos de dados de produção sem mover ou copiar dados .

Integrações com Azure e Microsoft

A Databricks aprofundou sua integração com o ecossistema Azure, anunciando várias capacidades em conjunto:

• Copilot Studio e GitHub Copilot: Os usuários podem criar agentes no Copilot Studio que raciocinam sobre todo um workspace do Azure Databricks por meio de uma única conexão MCP (Model-Centric-Protocol) .
• Genie para Microsoft Teams e M365 Copilot (Beta): Os usuários podem marcar o Genie em uma conversa no Teams e receber respostas contextuais diretamente do seu ambiente Azure Databricks .
• Suplemento do Azure Databricks para Excel (Pré-visualização Pública) e ingestão nativa de dados do Excel (disponível para todos) permitem análises autônomas a partir de planilhas .
• Databricks CustomerLake: A primeira plataforma de dados do cliente nativa do lakehouse, revelada para o Azure Databricks .

Essas integrações sugerem uma estratégia para embutir as capacidades de governança e IA da Databricks nas próprias ferramentas de colaboração onde as decisões de negócios acontecem, em vez de exigir que os usuários alternem para uma interface de análise separada.

O que isso significa para a arquitetura de dados corporativa

Em conjunto, os anúncios do summit representam uma aposta de plataforma coerente: a de que a próxima geração de aplicações empresariais será agentiva, em tempo real e governada. O LTAP remove a divisão entre transacional e analítico, o Lakehouse//RT elimina o compromisso com a latência para consultas analíticas, e a família Genie fornece a camada de orquestração dos agentes.

Se bem-sucedida, essa arquitetura pode reduzir o número de partes móveis em uma pilha de dados corporativa típica — menos bancos de dados, menos pipelines, menos camadas de serviço — enquanto fornece aos agentes de IA o contexto governado e em tempo real de que precisam para agir de forma autônoma sobre os dados de negócio.

A Databricks não está sozinha nessa corrida pela convergência, mas com o Lakebase já realizando 12 milhões de inicializações diárias de banco de dados e um evento de 30.000 participantes reforçando seu ecossistema, o anúncio do LTAP marca um marco significativo na evolução da arquitetura lakehouse, de uma plataforma de análise para uma espinha dorsal de dados operacionais .