Na era dos agentes, a distância entre o mundo onde o negócio acontece e o mundo onde ele é analisado vira dívida de arquitetura, com efeito direto em risco, governança e capacidade de decisão.
Durante décadas, a arquitetura de dados aceitou uma divisão quase natural: de um lado, os sistemas transacionais; do outro, os ambientes analíticos. Funcionou por muito tempo. Na era dos agentes, essa divisão cobra juros.
”The foundation is invisible until it isn’t”.
No Data + AI Summit 2026, a Databricks anunciou o LTAP, ou Lake Transactional/Analytical Processing: uma arquitetura que unifica transações, analytics, streaming e dados operacionais numa única cópia de armazenamento no lake. Segundo Ali Ghodsi, CEO e cofundador da Databricks,
“for decades, complicated data infrastructure was a tax that teams were forced to pay. Then agents arrived (…) The infrastructure that powered the last era of computing is now the bottleneck that no one can afford. LTAP removes it.”
A ambição declarada é alta: refazer a fundação da arquitetura de dados justamente quando, segundo a própria Databricks, a IA já ajuda desenvolvedores a escrever cerca de 50 vezes mais aplicações do que antes, boa parte delas operada por agentes.
O problema: a empresa opera em um lugar e decide em outro
Na arquitetura tradicional, o dado nasce nos sistemas operacionais: core banking, ERP, CRM, plataformas de atendimento, e-commerce, sistemas de risco, cobrança, logística, sinistro ou antifraude. É o mundo OLTP, criado para registrar a operação.
Depois, esse dado é movido por pipelines de ETL, ELT, CDC, batch ou streaming para os ambientes analíticos. Lá ele é transformado, agregado, modelado e disponibilizado para BI, ciência de dados, governança, modelos de IA e aplicações de negócio. É o mundo OLAP, criado para interpretar a operação.
Esse modelo criou valor e criou dependências. Cada cópia de dado aumenta o custo de armazenamento, processamento e controle, e cada pipeline soma latência, fragilidade e manutenção. Some a isso a inconsistência que cada camada intermediária introduz, e as políticas próprias de acesso, auditoria, lineage e retenção que cada ambiente separado exige.
O resultado é conhecido por muitos CIOs e CTOs. A empresa investe em dados e ainda discute qual número é o certo. Investe em IA e tem dificuldade de explicar de onde veio o dado. Moderniza plataformas e, mesmo assim, segue presa a pipelines críticos e pouco visíveis.
A pergunta que importa hoje é uma só: a empresa tem uma fundação confiável para transformar dado operacional em decisão auditável?
O que é LTAP
LTAP significa Lake Transactional/Analytical Processing. Segundo a Databricks, a proposta aproxima processamento transacional, processamento analítico, streaming, aplicações de dados e IA numa fundação lakehouse governada, eliminando ETL, réplicas e pipelines por construção.
Em termos simples, o LTAP une o lugar onde o negócio acontece com o lugar onde o negócio é analisado. Aplicações, analytics e agentes passam a trabalhar sobre a mesma cópia de dado, com governança unificada via Unity Catalog.
Essa convergência convive com sistemas legados. Sistemas transacionais antigos continuam existindo, e nem todo workload OLTP ou OLAP precisa migrar para uma única plataforma. Ainda assim, a separação rígida entre dado operacional e dado analítico fica cada vez menos sustentável para quem quer operar IA em produção.
Por que isso importa na era dos agentes
A IA generativa trouxe uma primeira onda de produtividade: copilots, assistentes, busca semântica, geração de texto, análise de documentos e automação de tarefas. A próxima onda é mais exigente, porque agentes executam ações.
Um agente corporativo consulta o status de um cliente, analisa risco, recomenda uma ação, aciona um workflow, registra a decisão e monitora o impacto. Ele opera em ciclo contínuo: lê contexto, interpreta dados, decide ou recomenda, executa, registra o resultado e aprende com o retorno.
Esse ciclo exige dado fresco, contexto confiável, governança consistente e capacidade de escrever de volta nos sistemas certos. Quando o dado operacional vive num ambiente, o analítico em outro, os modelos numa terceira camada e os agentes operam por fora dessa cadeia, a arquitetura fica frágil. O agente lê dado atrasado, ignora uma política, usa uma métrica inconsistente, age sem rastreabilidade ou gera um resultado difícil de auditar.
Para empresas reguladas ou de operação crítica, isso é um problema de confiança, com impacto direto em risco e auditoria.
Como a Databricks apresenta o LTAP
O LTAP se apoia no Lakebase, lançado em 2025 como banco de dados serverless em Postgres integrado ao lakehouse. Segundo a Databricks, o Lakebase já serve milhares de clientes, incluindo Block, Ensemble, Superhuman e Zillow, e processa 12 milhões de lançamentos de banco de dados por dia. Como resume Grant Veazey, CTO da Ensemble, sobre a base construída com Databricks: “Lakebase and LTAP extend that foundation by unifying operational and analytical workloads on a single layer, giving our RCM-native AI the real-time access it needs to perform in live operations.”
A governança roda sobre o Unity Catalog: identidade, permissões, auditoria e lineage unificados para dados e ativos de IA, tanto no Lakebase quanto no lakehouse. Ao redor dessa fundação, a Databricks também apresentou outras peças do que chama de era agentic: o Genie One como copiloto agentic de dados, o Agent Bricks para construir agentes sobre dados próprios, o Omnigent para políticas de governança de agentes, o OpenSharing para compartilhamento de dados entre organizações, e aplicações como Lakewatch (SIEM agentic) e CustomerLake (CDP agentic).
Juntas, essas peças sustentam a narrativa central da Databricks: aplicações, analytics, agentes e governança operam sobre uma fundação comum. É importante notar que, segundo o próprio press release, o LTAP “is coming soon as a part of Lakebase”: trata-se de uma arquitetura anunciada, ainda não em disponibilidade geral.
Outra peça dessa fundação é o Lakehouse//RT, novo warehouse em tempo real, hoje em beta, cujo motor Reyden entrega, segundo testes da própria Databricks, até 16 vezes mais performance que camadas de serving dedicadas, com latência sub-100 milissegundos a 12.000 queries por segundo.
Por que isso é relevante
A separação OLTP/OLAP sobreviveu a todos os ciclos de tecnologia, de Oracle e Teradata a Snowflake e Redshift. Os nomes mudaram a cada década; a arquitetura permaneceu. Hoje os concorrentes respondem por integração: a Snowflake avança com a própria estratégia Postgres e a Microsoft constrói o Azure HorizonDB. A Databricks aposta em eliminar a separação; os concorrentes, em integrá-la melhor.
Já houve um ensaio dessa história. Quando a Databricks cunhou o termo “lakehouse” em 2020, a ideia foi tratada como anti-padrão, e hoje boa parte dos grandes provedores de nuvem usa o termo. O ceticismo com o LTAP repete o padrão. Ainda assim, o contraponto honesto sustenta a régua: ninguém uniu OLTP e OLAP em quatro décadas, e a tese precisa ser provada em escala, em workloads críticos e sob exigências regulatórias, já que o próprio LTAP segue em fase de lançamento.
O impacto para CIOs e CTOs
Para CIOs e CTOs, o LTAP é um sinal de mercado: a arquitetura de dados entra em uma nova fase. Durante anos, a prioridade foi consolidar dados para análise e, depois, escalar plataformas de analytics e machine learning. Agora a pressão é construir uma fundação capaz de sustentar agentes, aplicações inteligentes e decisões automatizadas com confiança.
Isso muda a agenda executiva. A conversa amplia o escopo: da modernização do data stack para a capacidade da organização de decidir e agir com confiança em ambientes complexos. Por isso, algumas perguntas se tornam centrais:
- Quantas cópias existem dos dados críticos do negócio?
- Qual a latência entre um evento operacional e sua visibilidade analítica?
- Quem governa o dado quando ele sai do sistema transacional e chega à camada de IA?
- O lineage permite rastrear uma decisão desde o evento original até a ação tomada?
- Os agentes podem ler e escrever dados com controle, contexto e auditoria?
- A arquitetura atual reduz ou aumenta a superfície de falha?
- A empresa tem uma fundação de dados ou uma coleção de integrações frágeis?
Essas perguntas pesam mais do que a escolha de uma ferramenta isolada, já que o risco mora na desconexão entre o banco de dados, o pipeline e o modelo, um efeito que nenhum deles resolve sozinho.
O LTAP muda onde a complexidade é resolvida
O LTAP não resolve sozinho a complexidade das organizações. Grandes empresas seguem com sistemas legados, domínios distribuídos, exigências regulatórias, restrições de residência de dados, contratos históricos, aplicações críticas e múltiplas plataformas.
A questão é outra. O LTAP força uma discussão de arquitetura: quais dados, decisões e aplicações devem continuar distribuídos em camadas separadas, e quais devem convergir para uma fundação governada comum?
Essa decisão exige critério. Nem todo workload transacional pertence ao lakehouse, nem todo caso analítico exige real-time. A permissão de um agente para escrever de volta em sistemas operacionais pede o mesmo critério, avaliado por domínio, criticidade, latência, governança, custo, dependência operacional e impacto no negócio. Assim, a adoção madura começa pelo diagnóstico da fundação.
A leitura estratégica para empresas de operação crítica
Para empresas de alta complexidade, o LTAP ilumina uma dívida que costuma ficar invisível: a fragmentação entre os sistemas que sustentam a operação e os sistemas que sustentam a decisão. Ela aparece em sintomas conhecidos:
- múltiplas versões da verdade;
- dashboards que não batem com os sistemas operacionais;
- pipelines críticos sem ownership claro;
- decisões executivas baseadas em dados defasados;
- baixa rastreabilidade entre evento, análise e ação;
- dificuldade de escalar IA para produção;
- governança inconsistente entre dados, modelos e aplicações;
- dependência de integrações manuais ou reverse ETL;
- aumento da superfície de falha.
Na IA agêntica, esses sintomas ficam mais graves, já que quanto maior a autonomia dos sistemas, maior precisa ser a clareza da fundação. Agentes amplificam as consequências de uma arquitetura fragmentada.
O que isso significa para a estratégia de dados e IA
Antes de acelerar a adoção de agentes, avalie se a fundação de dados está pronta para sustentar decisões automatizadas. A pergunta vai além de ter modelos, pipelines ou uma plataforma moderna: é se a arquitetura permite que dados operacionais, dados analíticos, contexto de negócio, governança e execução convivam com confiança. Isso exige uma visão integrada de fundação:
- Origem e ownership dos dados críticos. Quais dados sustentam decisões relevantes? Onde nascem? Quem responde por qualidade, atualização e significado?
- Latência decisória. Quanto tempo passa entre um evento operacional e sua disponibilidade para análise, automação ou ação?
- Governança ponta a ponta. As políticas de acesso, auditoria, lineage e retenção acompanham o dado ao longo de toda a jornada?
- Capacidade de escrita segura. Aplicações e agentes registram decisões ou acionam sistemas com controle, sem criar risco operacional?
- Observabilidade da decisão. A organização rastreia não apenas sistemas e pipelines, mas decisões, impactos e responsáveis?
- Custo estrutural da fragmentação. Quanto da operação de dados existe só para compensar a separação entre sistemas transacionais e analíticos?
Essas dimensões separam modernização real de troca de ferramenta.
O papel da TreeID
Na TreeID, lemos o LTAP como sinal de uma mudança maior: dados, integração, IA, governança e operação formam uma fundação única, não disciplinas isoladas geridas em paralelo.
Quando o dado operacional não conversa com o analítico, a governança não acompanha a execução, a IA opera sem contexto suficiente e a arquitetura depende de integrações frágeis, o gargalo passa a ser a decisão. A TreeID atua na raiz: ajuda organizações complexas a entender a fundação de dados, identificar riscos estruturais, decidir caminhos de arquitetura e construir a capacidade certa com o time que assume a corresponsabilidade da entrega.
Em resumo, o LTAP funciona melhor como convite a uma pergunta mais importante: sua arquitetura aproxima ou distancia o evento da decisão? O próximo passo é avaliar a fundação de dados antes de escalar agentes em produção. Fale com a TreeID sobre o Foundation Review para dados e IA. Somos parceiros Databricks.
Fontes
- Databricks Launches LTAP: The First Lake Transactional/Analytical Processing Architecture — press release, 16/jun/2026
- From monolith to Lakebase to LTAP: rethinking the database from storage up — Reynold Xin, 30/jun/2026
- A New Era of Databases: Lakebase — Ali Ghodsi et al., 12/jun/2025 (atualizado 24/fev/2026)
- Introducing Lakehouse//RT — 16/jun/2026
- Lakebase (página de produto)
- Unity Catalog · OpenSharing · Lakewatch · CustomerLake
- Databricks Launches Genie One — 16/jun/2026
- Contextual Policies in Omnigent — 7/jul/2026