What Lakehouse//RT and LTAP Are—and Why They Matter
Lakehouse//RT and LTAP are Databricks innovations that bring real-time analytics and transactional analytical processing directly into the lakehouse architecture, merging operational, streaming, and analytical workloads on a single governed copy of data to remove ETL pipelines, data replicas, and separate serving systems that add latency, cost, and complexity for modern data platforms. For years, organizations split workloads across operational databases, streaming engines, and analytical warehouses, then stitched them together with change data capture and sync pipelines. Lakehouse//RT targets this sprawl from the analytics side, delivering millisecond-latency queries directly on Delta Lake and Apache Iceberg tables powered by the new Reyden compute engine. LTAP attacks the problem from the transactional side by unifying OLTP and OLAP on one storage layer using Lakebase, Databricks’ Postgres-compatible engine on object storage. Together, they aim to turn the lakehouse into a single data platform consolidation layer where both transactions and analytics operate in real time without creating more silos.
Lakehouse//RT: Real-Time Analytics Inside the Lakehouse
Lakehouse//RT brings real-time analytics directly into the lakehouse architecture by eliminating separate streaming and serving stacks. Instead of copying data into proprietary stores, Lakehouse//RT queries governed Delta Lake and Apache Iceberg tables in place, under Unity Catalog, so permissions and governance remain consistent. Databricks reports that on standard analytical benchmarks, Lakehouse//RT delivers sub-100 millisecond latency at 12,000 queries per second, and customers have seen up to 16x better performance than existing specialized real-time serving stacks. The new Reyden engine is built for high concurrency, supporting tens of thousands of simultaneous users and AI agents that depend on low-latency queries for continuous reasoning loops. Because Lakehouse//RT can make almost any table real-time queryable within minutes, analytics teams gain fresh data without ETL delays, and platform teams remove change data capture pipelines, sync jobs, and separate permission layers that previously stood between the lakehouse and interactive real-time workloads.
LTAP: Unifying OLTP and OLAP Through the Lake
LTAP (Lake Transactional/Analytical Processing) is Databricks’ answer to unifying transactional and analytical workloads without collapsing them into a single monolithic engine. Instead of hiding pipelines, LTAP unifies data at the storage layer: operational data written by Lakebase becomes immediately available in the lake for analytics, on the same object storage that powers the lakehouse. Databricks describes LTAP as “the world’s first LTAP platform,” combining Lakebase—serverless Postgres on open object storage—with the Lakehouse under one governance model and storage layer. By separating compute from storage yet sharing the same tables through open formats like Delta and Iceberg, LTAP allows transactional and analytical workloads to scale independently with strict isolation. This design addresses long-standing issues with HTAP systems, which often compromised performance and isolation, and with zero-ETL approaches that still depended on concealed CDC pipelines. In the LTAP model, transactional analytical processing becomes a native property of the lake, rather than an afterthought.
From Data Silos to a Single Real-Time Lakehouse
Traditional data architectures created silos by design: OLTP databases for applications, OLAP warehouses for analytics, and separate streaming or serving layers for low-latency use cases. Each layer produced its own copy of data, required its own pipelines, and introduced delays that made “real-time analytics” closer to near-real-time snapshots. For analytics teams and AI agents that depend on live operational context, this gap often meant stale dashboards and reactive decisions. Lakehouse//RT and LTAP directly address this fragmentation through data platform consolidation. Lakehouse//RT removes dedicated serving clusters for real-time dashboards and AI-powered applications, while LTAP removes ETL and replicas between operational stores and the lakehouse. Because everything runs on open storage and formats under a single governance plane, data moves less, becomes queryable sooner, and stays consistent. The result is shorter latency from transaction to insight, fewer moving parts to maintain, and a clearer path to transactional analytical processing on one platform.
How This Shifts the Competitive Data Platform Landscape
By putting real-time analytics and transactional workloads on the same open lakehouse foundation, Databricks is redrawing the lines between data warehouses, streaming platforms, and operational databases. Competitors have tried to bridge OLTP and OLAP with HTAP engines or “zero ETL” integrations, but those approaches either forced all workloads into a single engine or kept the underlying CDC pipeline alive. LTAP’s storage-level unification and Lakehouse//RT’s real-time execution on Delta and Iceberg give Databricks a differentiated position: a single lakehouse architecture capable of both high-throughput transactions and low-latency analytics. In practical terms, this increases pressure on vendors that rely on proprietary serving layers or closed-formats warehouses to support real-time analytics. As AI agents drive demand for always-on, low-latency access to complete enterprise data, architectures with copies and lagging pipelines look less viable. The combined Lakehouse//RT and LTAP approach signals a shift toward open, unified platforms where transactional analytical processing is built into the lakehouse itself.
