What LTAP Is and Why It Targets AI Agents First
Lake Transactional/Analytical Processing (LTAP) is Databricks’ new architecture that unifies transactional, analytical, and streaming workloads on a single copy of data in an object-storage lake, designed primarily as an AI agent database rather than a human-facing system. Instead of running separate OLTP and OLAP databases, LTAP keeps all data in one governed lakehouse design while isolating workloads through different compute engines. Databricks argues that enterprises can no longer afford the complexity of ETL pipelines, replicas, and separate serving layers when AI agents read, reason, and act on data in tight loops. As co‑founder and CEO Ali Ghodsi said at the Data + AI Summit, “The infrastructure that powered the last era of computing is now the bottleneck that no one can afford. LTAP removes it.” For Databricks, this is the first architecture built from the ground up for autonomous agents instead of human dashboard users.
From Dual Databases to a Single Lakehouse Design
For roughly forty years, enterprises have depended on two separate database stacks: online transactional processing systems for orders, payments, and inventory; and online analytical processing systems for reporting, dashboards, and data science. That split led to armies of ETL jobs, change data capture pipelines, and near-duplicate copies of the same data scattered across warehouses and serving layers. Databricks’ LTAP architecture aims to collapse this pattern by unifying transactional analytical processing in the lake itself. All operational data written through Lakebase is stored once in open table formats such as Delta or Iceberg, then immediately available for analytics without copying or transformation. Unlike HTAP systems that tried to push all workloads into one monolithic engine, LTAP separates compute while unifying storage and governance, so application transactions and large analytical scans can scale independently yet see the same consistent data.
Lakebase: Postgres for the AI Agent Database Era
At the heart of the LTAP architecture is Lakebase, Databricks’ Postgres-based operational database that runs directly on cloud object storage. Lakebase separates compute from storage and writes data into the lake in open formats, forming the transactional half of the AI agent database. Databricks says Lakebase now serves thousands of customers and handles 12 million database launches per day, which gives it the operational footprint needed to carry “business‑critical workloads.” Recent upgrades add native vector search, full‑text search, and real-time ingestion via Zerobus from the Lakeflow Connect suite, all features aimed at agentic applications that mix structured transactions and unstructured context. Git‑style branching lets AI agents spin up isolated copies of databases for experimentation, then discard or merge them later. Ghodsi framed this behavior simply: agents branch, test, and iterate far faster than humans, so the database has to keep up.
Lakehouse//RT and the End of Separate Real-Time Serving Layers
The analytical side of LTAP is Lakehouse//RT, a real-time engine that runs directly on Delta and Iceberg tables in the lakehouse. Instead of standing up a separate low‑latency serving system and copying data into it, enterprises can query their lakehouse tables with millisecond‑level response times and high concurrency. Lakehouse//RT is powered by a vectorized engine called Reyden and is designed to remove yet another layer of replicas, pipelines, and governance gaps. Databricks highlights that transactional and analytical workloads remain strictly isolated at the compute layer, even as they share the same storage. According to PointClickCare’s SVP of engineering, Mehrshad Setayesh, Lakehouse//RT “ran more than a third faster on average than our prior warehouse on our healthcare dataset, with 10x faster queries,” while eliminating the need for a separate real-time system.
What LTAP Signals for Enterprise Data Strategy in the Agentic Era
LTAP is less a single product than a statement about where enterprise data infrastructure is heading as AI agents become first‑class users. Databricks’ acquisitions of serverless Postgres startup Neon and Mooncake Labs helped it assemble the building blocks: Postgres‑compatible transactions on open storage, lakehouse governance, and vector‑aware real-time analytics. The company positions LTAP as an answer to the shortcomings of both HTAP and “zero‑ETL” approaches, which either merged engines in ways that hurt performance or hid pipelines without removing duplication. By centering data at the lake storage layer and treating both applications and analytics as peers on top, LTAP reframes the lakehouse not only as a BI platform but as the core AI agent database. For enterprises, the shift means designing schemas, governance, and operations with autonomous code as the primary consumer, and humans increasingly as secondary readers of that same shared data foundation.
