Durante décadas, os profissionais de dados têm lutado com o desafio de gerenciar bancos de dados operacionais e analíticos em uma abordagem unificada que não introduza latência e degradação de desempenho.
Os agentes tornaram o problema estrutural. Um sistema que raciocina continuamente e age com base em dados em tempo actual não pode tolerar um pipeline entre ele e as informações de que necessita para agir.
No Information + AI Summit na terça-feira, a Databricks anunciou dois produtos que visam o colapso dessa infraestrutura. Lakehouse//RT oferece latência de consulta em milissegundos diretamente em tabelas Delta e Iceberg governadas, eliminando o nível de serviço dedicado em tempo actual que as empresas mantêm junto com seus lakehouses. LTAP, abreviação de Lake Transactional/Analytical Processing, armazena dados transacionais nativos do Postgres nos formatos Delta e Iceberg desde o ponto de gravação, removendo os pipelines ETL que conectam sistemas operacionais e analíticos há décadas.
Reynold Xin, cofundador da Databricks, descreveu uma pilha de dados mais simples como “o Santo Graal para os agentes” em um briefing com VentureBeat, argumentando que à medida que os usuários codificam mais aplicativos, os agentes raciocinam analiticamente sobre esses aplicativos precisam da infraestrutura subjacente fora do caminho para se moverem rapidamente.
“Os agentes realmente preferem uma pilha muito mais simples, porque podem se mover muito mais rápido”, disse ele.
LTAP aposta na unificação da camada de armazenamento onde o HTAP tentou a convergência de mecanismos
Muitos fornecedores tentaram várias abordagens ao longo das décadas para unificar dados analíticos e transacionais.
Em 2014, a empresa de análise Gartner cunhou o termo HTAP, um acrônimo que significa Processamento Transacional/Analítico Híbrido como uma forma de descrever fornecedores que tentaram unificar os dois tipos de bancos de dados. Fornecedores como MemSQL (agora conhecido como SingleStore), SAP HANA e MySQL Heatwave da Oracle estão entre os muitos fornecedores de HTAP no mercado.
LTAP é a resposta do Databricks ao HTAP, usando a arquitetura Lakebase para unificar dados na camada de armazenamento em vez de no nível do mecanismo. Lakebase é o serviço de banco de dados PostgreSQL baseado em nuvem sem servidor da Databricks que se tornou disponível em fevereiro.
“Para nós, o HTAP é mais um fracasso da indústria do que um sucesso”, disse Xin.
A abordagem LTAP vai para a camada de armazenamento em vez da camada de consulta. Lakebase armazenava anteriormente dados Postgres no formato Postgres no armazenamento de objetos, exigindo conversão antes que os mecanismos analíticos do Lakehouse pudessem usá-los com eficiência. Com o LTAP, os dados transacionais chegam diretamente no formato Delta ou Iceberg, compartilhando a mesma cópia lida pelas cargas de trabalho analíticas. Postgres continua sendo o mecanismo transacional. Spark e Lakehouse continuam sendo o motor analítico.
“A questão toda é, ei, você usa a melhor ferramenta para o trabalho no nível do mecanismo de consulta, apenas garantimos que o armazenamento subjacente seja uma única cópia dos dados”, disse Xin.
O desafio central da engenharia é a latência. O armazenamento de objetos carrega tempos de resposta na faixa de segundos, muito lentos para cargas de trabalho OLTP que exigem desempenho inferior a um milissegundo. Lakebase lida com isso por meio de uma camada de cache entre instâncias de computação do Postgres e armazenamento de objetos. A principal decisão de design é onde ocorre a conversão da coluna: a capacidade ociosa da CPU nessa camada de cache executa a conversão de linha para coluna antes que os dados cheguem ao armazenamento de objetos.
“Quando você converte dados de linha para coluna, eles são compactados mais de 10 vezes, normalmente, então agora você reduz substancialmente o custo de rede dessa camada básica de cache entre essa camada de cache e os armazenamentos de objetos”, disse Xin.
Lakehouse // RT oferece latência de consulta em milissegundos em dados do Lakehouse ao vivo sem uma camada de serviço separada
Lakehouse//RT é a resposta da Databricks ao nível de serviço dedicado em tempo actual – as empresas de sistemas separados mantiveram ao lado de seus lakehouses para lidar com consultas de baixa latência, ao custo de cópias de dados, governança dividida e agentes de complexidade de pipeline não podem contornar. Os principais recursos do Lakehouse // RT incluem:
Mecanismo de computação Reyden: Construído especificamente para atendimento de alta simultaneidade e baixa latência, o Reyden consulta tabelas Delta e Iceberg diretamente, sem mover dados para fora do lago.
Latência e taxa de transferência: Lakehouse//RT oferece latência inferior a 100 ms a 12.000 consultas por segundo, com tempos de resposta tão baixos quanto 10 ms em conjuntos de dados menores e desempenho até 16 vezes melhor do que as pilhas de serviços dedicados existentes.
Governança e acesso a dados: Cada consulta é executada na estrutura de governança do Unity Catalog, sem camada de permissões separada, sem cópias de dados e sem pipelines de ingestão.
Transformação VB · 14 a 15 de julho · Menlo Park · Camadas de contexto agente
Seus agentes são tão bons quanto os dados que podem alcançar.
As sessões no Rework cobrem as arquiteturas RAG que alimentam os sistemas de agentes em escala – incluindo como as empresas estão conectando agentes a dados genômicos, clínicos e empresariais em tempo actual.
Veja a agenda completa →
Os analistas veem o enquadramento da agência e a abordagem do formato aberto como os verdadeiros diferenciais
O problema que ambos os produtos abordam está bem documentado entre as equipes de dados corporativos, mas os analistas fazem uma distinção entre o ponto problemático e a afirmação específica que o Databricks está fazendo.
“As empresas têm HTAP, streaming, armazéns em nuvem e lojas operacionais há anos”, disse Stephanie Walter, líder de prática de AI Stack da HyperFRAME Analysis, à VentureBeat. “O que é diferente é o enquadramento da IA de agência.”
Walter observou que os agentes precisam de dados operacionais em tempo actual, contexto histórico, governança, recuperação e write-back no mesmo fluxo de trabalho.
“Esse é um forte argumento de arquitetura, mas a Lakebase ainda precisa provar que pode atender à latência, confiabilidade e maturidade operacional que os CIOs esperam”, disse ela.
Mike Leone, analista da Moor Insights and Technique, disse que o caminho para a diferenciação genuína é mais específico do que o próprio conceito de unificação. Ele também observou que a análise aberta em um knowledge lake é uma aposta importante agora, com muitos fornecedores fornecendo algum tipo de serviço.
“O movimento menos comum é permitir que as gravações transacionais também cheguem em formatos abertos, de modo que o banco de dados operacional não fique em uma caixa proprietária enquanto apenas a metade analítica estiver aberta”, disse Leone ao VentureBeat.
Ele acrescentou que a abordagem de formato aberto, combinada com Lakehouse//RT consultando dados ao vivo diretamente do lago, é o que dá à arquitetura um argumento confiável para aposentar toda uma linha de sistemas especializados.
A afirmação técnica que enfrentará o maior escrutínio é também a mais central. “A parte que eu ainda gostaria que seus engenheiros analisassem é como ambos os motores realmente compartilham uma cópia sem uma etapa de conversão silenciosa fazendo a sincronização no meio”, disse Leone.
O que isso significa para as empresas
Para os engenheiros de dados que avaliam sua pilha para cargas de trabalho de agente, a questão não é mais qual a melhor ferramenta a ser executada para cada trabalho, mas sim se a execução de ferramentas separadas ainda é defensável.
As empresas que construíram bases de dados operacionais separadas, níveis de serviço em tempo actual e lagos analíticos poderiam anteriormente tratar as lacunas entre eles como um fardo de manutenção. Os agentes revelam essas lacunas como um risco operacional: um sistema que raciocine além das fronteiras da governação encontrará as inconsistências mais rapidamente do que qualquer equipa humana.
O mercado está se afastando das camadas de serviços especializados mais rapidamente do que a maioria dos roteiros dos fornecedores previam. De acordo com o VB Pulse Q1 2026, uma pesquisa longitudinal de três ondas com mais de 100 organizações de funcionários, a intenção de recuperação híbrida triplicou de 10,3% para 33,3% ao longo do trimestre, enquanto a adoção de banco de dados vetorial independente diminuiu em todos os fornecedores rastreados. A mesma lógica de consolidação está agora atingindo o nível de serviço em tempo actual.
A abordagem tradicional — as melhores ferramentas para cada tipo de carga de trabalho, pipelines entre elas — foi construída para consumo analítico à velocidade humana. As cargas de trabalho dos agentes não toleram essa arquitetura.
“A dor que eles apontam, toda a cópia e sincronização entre sistemas operacionais e analíticos, é actual e cara, e qualquer pessoa que execute isso em grande escala sente isso”, disse Leone.
