What Lakehouse//RT and LTAP Mean in Plain Terms
Databricks Lakehouse//RT is a real-time analytics engine built on an LTAP (Lake Transactional/Analytical Processing) architecture that stores transactional and analytical data once in open formats, allowing AI agents and humans to query the same fresh, governed information without separate systems or complex sync pipelines. For decades, data stacks split into OLTP databases for transactions and OLAP warehouses for analytics, stitched together with ETL jobs and replicas. Databricks’ LTAP design keeps a single storage layer in the lakehouse and adds specialized compute engines on top, so operational workloads, historical analytics, and AI agents all operate on a unified data platform. Lakehouse//RT brings Lakehouse real-time analytics directly to Delta Lake and Apache Iceberg tables, removing the traditional “serving layer” that copied data into proprietary systems. The result is AI-native database architecture aimed at millisecond queries and high concurrency without duplicating data or fragmenting governance.
From Two Databases to One Unified Data Platform
Enterprises have long run two parallel worlds: online transactional processing systems to run the business, and analytical warehouses for reporting and BI. The cost was architectural sprawl, fragile pipelines, and data that was always slightly stale. Databricks’ LTAP proposal is to merge those into a single LTAP database design, where Lakebase handles operational workloads and the lakehouse handles analytics, all on one shared storage layer. Lakebase, built on a serverless Postgres core and expanded with technologies from Neon and Mooncake Labs, writes transactions directly to open table formats in the lake. Mooncake mirrors Postgres changes into the lakehouse in real time so analytics engines see the same data without ETL. This strategy reduces operational complexity by keeping governance, schemas, and security within one unified data platform instead of multiple overlapping stacks and custom sync logic.
AI-Native Database Architecture: Agents as First-Class Users
Databricks is designing LTAP for a world where AI agents, not people, are the main database users. Agents run loops, write and evaluate code, and hit data systems at a cadence humans never could. That changes database design priorities: concurrency, millisecond latency, and flexible experimentation become core requirements rather than edge cases. Lakebase adds features aimed squarely at AI agents, including native vector search and full-text search, so retrieval-augmented generation and semantic lookups work on operational data without extra systems. Through Git-style branching, an agent can clone an entire database state, try changes or simulations, and discard the branch without waiting for new infrastructure. According to Ali Ghodsi, “In a matter of months, organizations effectively doubled their workforce, just not with humans.” LTAP and Lakehouse//RT respond by making AI-native database architecture the baseline, not an afterthought bolted onto legacy OLTP and OLAP.
Lakehouse Real-Time Analytics Without a Separate Serving Layer
Lakehouse//RT focuses on Lakehouse real-time analytics by bringing sub-100 millisecond queries directly to Delta and Iceberg tables. Historically, companies cloned data into specialized serving systems to hit millisecond latency, trading simplicity for speed. That pattern created vendor lock-in, duplicated governance, and data that was never fully current. Lakehouse//RT, powered by the Reyden engine, collapses that pattern. It queries governed lakehouse tables in place and supports tens of thousands of concurrent users and agents. On standard benchmarks, Lakehouse//RT delivers sub-100ms latency at 12,000 queries per second, and customers report up to 16x better performance than prior real-time stacks. Every query runs under Unity Catalog governance with no separate permissions tier or CDC pipelines. This LTAP-aligned design lets AI agents act on fresh operational and historical data in one system, so product recommendations, anomaly detection, or automated decisions can update in near real time without architectural fragmentation.
