Em junho deste ano a Databricks em seu evento anual lançou o Lake Transactional/Analytical Processing, ou LTAP. Um ponto interessante para analisarmos é se de fato foi algo totalmente revolucionário ou novo nome para alguma coisa antiga, por isso vamos analisar as diferenças do LTAP para o HTAP, Hybrid Transactional and Analytical Processing, que foi lançada pela consultoria Gartner em 2014, trata-se de uma arquitetura de banco de dados desenhada para processar tanto transações operacionais (OLTP — como registrar vendas, atualizar cadastros ou gerenciar estoques) quanto cargas analíticas (OLAP — como gerar relatórios complexos e analisar tendências) utilizando um único motor de processamento.
A Databricks não afirma ter criado um único mecanismo que execute ambas as tarefas, eles argumentam explicitamente que o HTAP falhou porque tentou:
O problema que ainda resta é que dados operacionais brutos não respondem automaticamente a perguntas complexas de negócio, a separação lógica continua existindo. O time de dados ainda precisa limpar, modelar, aplicar regras de governança e criar contexto histórico para que se torne útil em uma entrega de produto de dado
LTAP vs HTAP
Agora, o LTAP o unifica o processamento transacional e analítico em uma única cópia dos dados na camada de armazenamento. O Lakebase, o recurso PostgreSQL gerenciado introduzido no ano passado, agora grava no Unity Catalog em formatos abertos — páginas do Postgres transcodificadas para Parquet colunar no armazenamento de objetos, expostas como Delta e Iceberg. As transações ainda são executadas no Postgres e as análises são executadas no Lakehouse
Fonte: imagem retirada do artigo do @mrpaulandriw da cloudformations.org
O LTAP não é um HTAP rebatizado, é quase o oposto. O HTAP tentou unificar tudo na camada de engine: um único motor para transações e análises. Isso resultou em recursos incompletos e falta de isolamento de performance. O LTAP, por sua vez, unifica apenas a camada de armazenamento e mantém dois motores especializados.
O Postgres (Lakebase) cuida das transações.
O Lakehouse cuida das análises.
Ambos usam uma única cópia lógica dos dados em object storage (páginas Postgres convertidas para Parquet e expostas como Delta/Iceberg), sem pipeline de replicação entre eles.
Exemplo Prático de uso
Cenário: um e-commerce que registra pedidos em um banco Postgres e quer um dashboard de vendas e um agente de IA que recomenda ações em tempo quase real.
Antes (sem LTAP)
O app grava pedidos no Postgres.
Um pipeline de replicação (CDC com Debezium/Kafka, ou um ETL noturno) copia os dados para o data lake.
Os dados chegam como uma segunda cópia, em Delta/Parquet.
A análise roda sobre essa cópia.
Problemas típicos:
Latência: o dashboard mostra dados de horas atrás (ou do dia anterior)
Duas cópias para governar, reconciliar e pagar.
Custo de engenharia: muito esforço gasto só movendo dados de A para B
E a tentativa do HTAP? Rodar análises pesadas no mesmo banco transacional fazia uma consulta analítica grande degradar os pedidos dos clientes.
Com LTAP
O app grava pedidos no Postgres (Lakebase).
Os dados já ficam gravados no object storage em formato aberto, registrados no Unity Catalog.
O Lakehouse consulta a mesma cópia, com um motor separado, então a análise não derruba a transação.
Os dados ficam disponíveis em segundos, sem pipeline de replicação.
O que o LTAP resolve: a replicação operacional → analítica, sem repetir o erro do HTAP de misturar os motores.
Porém, o trabalho para o engenheiro continua o transporte foi removido, mas a tradução continua sendo responsabilidade nossa, ou seja, a tabela pedidos ainda está modelada para o comportamento da aplicação e não para análise. Falta tratar cancelamentos e devoluções, guardar o histórico de mudanças de status, padronizar o que é "receita" e aplicar governança. O pipeline era apenas a parte mais visível da fronteira entre o mundo operacional e o analítico, resolver esse problema da semântica do dado continua sendo desafio.
Por isso, o armazenamento convergiu e o transporte convergiu, mas a semântica não. Modelos operacionais e analíticos são diferentes porque as perguntas feitas a eles são diferentes, e nenhuma quantidade de Parquet compartilhado concilia isso. Quando o pipeline deixa de ser o obstáculo, o design passa a ser o diferencial.
Risco com a IA
A inteligência artificial pode acelerar parte do trabalho, mas não dispensa essa necessidade citada. Um agente que lê uma tabela operacional sem modelagem será confiantemente errado, e bem mais rápido do que qualquer pessoa jamais foi. Como o LTAP tem justamente os agentes como motivação, com estado e memória gravados de forma transacional e lidos de forma analítica, a ausência de semântica pode custar caro.
O texto teve como referência um post do arquiteto @mrpaulandrew no site cloudformations