Lakehouse//RT and LTAP: A Unified Foundation for Real-Time Analytics
Databricks Lakehouse//RT and LTAP are a unified real-time analytics platform and architecture that bring transactional and analytical processing together on a single governed data lake, removing the need for separate databases, serving layers, and extract–transform–load pipelines across operational and analytical workloads. Unlike traditional data stacks that split online transaction processing from data warehousing, Databricks’ approach extends lakehouse architecture so the same Delta Lake or Apache Iceberg tables can support both millisecond queries and long-running analytics jobs. Lakehouse//RT focuses on low-latency querying for high-concurrency users and AI agents, while LTAP (Lake Transactional/Analytical Processing) ensures transactional analytical processing on one copy of data. For enterprises, this means data warehouse consolidation: fewer systems to run, fewer pipelines to maintain, and a single source of truth for applications, reports, and real-time decisioning.
Lakehouse//RT: Real-Time Analytics Directly on the Lakehouse
Lakehouse//RT is Databricks’ real-time layer that allows enterprises to run low-latency queries directly against governed Delta Lake and Apache Iceberg tables without a separate serving stack. Powered by the new Reyden compute engine, it is designed for tens of thousands of concurrent users and AI agents querying the same data. Databricks reports sub‑100 millisecond latency at 12,000 queries per second on standard benchmarks, and customers have seen up to 16x better performance than existing specialized real-time serving stacks. Because queries run inside Unity Catalog’s governance, there is no extra security model, no proprietary data format, and no change data capture sync layer to keep a second system updated. This keeps data truly current while removing operational overhead, allowing real-time analytics use cases to run on the same lakehouse architecture that already powers batch ETL and classic warehousing.
LTAP: Lake Transactional/Analytical Processing on One Copy of Data
LTAP (Lake Transactional/Analytical Processing) brings transactional analytical processing to the same lake storage that powers the Lakehouse, unifying operational, streaming, and analytical workloads on one copy of data. Instead of hiding or duplicating pipelines, LTAP “unifies data at the storage layer,” so operational data is immediately queryable for analytics without extract–transform–load jobs, replicas, or brittle change data capture. The architecture is built on Lakebase, Databricks’ serverless Postgres engine on open object storage, which already serves thousands of customers and handles 12 million database launches per day. Transactions use a Postgres interface, while analytics engines read open table formats such as Delta and Iceberg, with Unity Catalog providing a single governance model. This separation of compute and shared storage means transactional and analytical workloads can scale independently, preserving workload isolation while supporting data warehouse consolidation on a shared lakehouse architecture.
Eliminating Split Architectures and Reducing Latency and Complexity
Together, Lakehouse//RT and LTAP address a long-standing split between transactional and analytical systems that forced enterprises to maintain multiple platforms, redundant copies, and fragile pipelines. Historically, organizations deployed separate online databases, real-time serving layers, and data warehouses, accepting latency and complexity as the cost of insight. Databricks positions Lakehouse//RT as a replacement for standalone real-time serving stacks, and LTAP as an alternative to both hybrid transactional/analytical engines and “zero ETL” patterns that still rely on hidden change data capture. By consolidating under a single storage layer and governance model, enterprises can reduce infrastructure complexity, streamline access control, and cut synchronization failures. For AI agents that read, reason, and act in loops, this means consistent, fresh data without architectural compromises; for human users, it means faster dashboards, fewer broken pipelines, and a simpler real-time analytics platform to operate.
New Real-Time Use Cases: From Fraud Detection to Personalization
The combination of Lakehouse//RT and LTAP opens real-time analytics patterns that were hard to implement on separate transactional and warehousing stacks. Fraud detection systems can score transactions against the latest behavioral and historical data without copying events into a separate serving store. Dynamic pricing engines can query live sales, inventory, and external signals with millisecond response times while writing new transactions into Lakebase. Customer personalization teams can build features, aggregate profiles, and serve recommendations from the same governed lakehouse tables, rather than juggling operational databases, feature stores, and warehouses. Because the architecture maintains workload isolation yet shares one storage foundation, engineers can evolve schemas and applications without breaking analytical jobs. The result is a single, governed, real-time analytics platform where operational, streaming, and warehousing use cases coexist, making the lakehouse architecture a central hub for both transactional and analytical innovation.
