Databricks' Lakehouse//RT Kills the Hidden Tax on Real-Time Data

Databricks launches Lakehouse//RT, a new real-time warehouse powered by the Reyden engine that delivers millisecond query latency directly on Delta and Iceberg tables, no data copies required.

·
·
  • Databricks launches Lakehouse//RT, a real-time data warehouse delivering millisecond query latency directly on Delta and Iceberg tables without data movement.
  • Powered by Reyden, a new fully asynchronous compute engine built for high-concurrency, low-latency workloads at tens of thousands of concurrent users and agents.
  • Up to 16x faster than existing real-time serving stacks in preview; sub-100ms latency at 12,000 queries per second on standard benchmarks.
  • No separate serving layer needed — eliminates CDC pipelines, data copies, and governance duplication; all queries run natively under Unity Catalog.
  • Now in Beta for select read-only workloads, with a 30% introductory discount on usage through January 2027.
  • Direct threat to dedicated OLAP engines like ClickHouse, Druid, and Pinot used as real-time side stacks alongside Databricks lakehouses.

For years, the dirty secret of enterprise data platforms was a hidden tax buried in every real-time dashboard: a separate serving layer sitting alongside your lakehouse, holding a stale copy of your data, with its own pipelines, its own security rules, and its own failure modes. Databricks is now taking direct aim at that architecture with the launch of Lakehouse//RT, a real-time data warehouse built natively into the lakehouse that promises millisecond query latency without moving a single byte of data.

Announced at the Data + AI Summit, Lakehouse//RT is powered by Reyden, a new compute engine built for the concurrency and latency demands of modern agentic enterprises, and is now available in Beta. The announcement was co-authored by Databricks co-founders Nong Li, Shoumik Palkar, Shant Hovsepian, Mostafa Mokhtar, and Reynold Xin.

The Tax You Were Already Paying

For years, enterprises that needed low latency at high concurrency had one option: stand up a separate real-time serving layer alongside the lakehouse. But that serving layer brings vendor lock-in, increased infrastructure costs, fragmented governance, and data that's never truly real time because it's always a copy , leaving enterprises with a forced compromise: accept latency or fragment the stack.

Databricks frames this as a three-way cost: you pay in data duplication (extracting data from open formats like Delta and Iceberg into proprietary storage), you pay in governance (re-defining security policies in a second system that inevitably drifts from the first), and you pay in engineering (someone has to own, debug, and run that pipeline). And after all of that, the serving layer still can't run all your queries , the moment a query gets complex, with joins or window functions, or the data gets big, it collapses.

The timing is also driven by a new class of consumer: AI agents. Agents are always-on, reasoning in loops, and their ability to act depends entirely on their ability to query complex enterprise data fast. Lakehouse//RT was built to eliminate that compromise, querying Delta and Iceberg tables directly in the governed lakehouse, giving AI agents and humans access to fresh, complete, and trusted data without copying or moving it.

What Reyden Actually Does

Reyden's fully asynchronous execution model delivers response times as low as 10 milliseconds on smaller datasets and 100 milliseconds on larger ones, without latency degrading as throughput climbs into the tens of thousands. The key architectural insight is that Reyden queries your existing Delta and Iceberg tables directly , there is no ingestion step, no proprietary format conversion, and no synchronization pipeline to maintain.

Three benchmark dimensions show where this matters most:

  • Under load: Tested against leading alternatives on query latency as throughput is pushed from a handful of queries per second into the thousands, the alternatives all behave the same way , latency holds for a while, then climbs, and then the engine stops responding altogether. Lakehouse//RT stays flat across the entire range.
  • At scale: Running TPCH (a standard decision-support benchmark covering large table scans, multi-table joins, and aggregations) from small datasets up to a terabyte, Lakehouse//RT keeps latency low as data grows. At large scale factors, two of the three alternatives tested failed to run at all.
  • On hard queries: On TPCDS (a more demanding benchmark with deep multi-table joins, subqueries, and window functions), one competing alternative ran as much as 25 times slower, and failed to finish at the largest scale.
Bar chart comparing query latency across Vendor 1 Gen 2, Vendor 2, and Reyden at different TPCDS scale factors

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 their existing specialized real-time serving stacks.

What's Under the Hood

Beyond raw speed, Lakehouse//RT ships with two compute management features that change how teams operate warehouses:

  • AUTO sizing: You no longer pick a t-shirt size. Databricks automatically determines the right baseline compute for your workload, removing the guessing game of sizing up when queries slow down and back down to save cost.
  • Incremental autoscaling: Traditional warehouses handle concurrency spikes by spinning up whole copies of themselves , 2x, then 3x, then 4x. Lakehouse//RT features intelligent autoscaling that scales up quickly to meet demanding workloads, while scaling down all the way to zero during idle periods, so you get real-time performance without paying for unused compute.

Every query runs within Unity Catalog's governance framework, including policies, permissions, and auditing , no separate governance layer to maintain, no gaps between analytical serving and the rest of the enterprise data estate. It's also worth noting the distinction from Lakebase, Databricks' serverless Postgres offering: Lakehouse//RT is a high-speed engine built for low latency and high concurrency running massive OLAP queries straight out of your data lake, while Lakebase is an OLTP database meant for pinpoint lookups and updating app data.

Early Customers Are Already Seeing It

The preview cohort spans industries where latency is a business-critical metric. A few standout results:

  • Meta Enterprise: Query results returning in tens of milliseconds on lake data, without a separate system.
  • SES (satellite connectivity): Operations dashboards running on billions of rows of live telemetry, 20x faster than previous query times, at a fraction of the cost.
  • Enverus (energy data platform): Queries returning up to 100x faster than their specialized real-time engine, collapsing a separate analytics stack into a single unified lakehouse.
  • Cisco: 5x improvement in threat lookup response time on live data.
  • Magnite (ad tech): Consistent sub-200ms performance on core dashboard queries across hundreds of queries per second.
Scatter plot comparing P90 latency vs throughput for Vendor 1 Gen 2 and Reyden on TPC-H Q6 benchmark

Who Wins, Who Loses

The clearest winners are existing Databricks customers who have been running a hybrid stack , maintaining a specialized real-time layer like Apache Druid, ClickHouse, or Pinot alongside their lakehouse. For them, Lakehouse//RT is a direct path to eliminating that second system, with all the governance and cost savings that come with it. More than 20,000 organizations worldwide , including adidas, AT&T, Bayer, Block, Mastercard, Rivian, Unilever, and 70% of the Fortune 500 , rely on Databricks , which gives this launch significant reach from day one.

The losers are the dedicated real-time OLAP vendors. Many vendors have tried various approaches over the decades to unify analytical and transactional data , back in 2014, Gartner coined the term HTAP (Hybrid Transactional/Analytical Processing) to describe vendors that attempted to unify the two types of databases, including MemSQL (now SingleStore), SAP HANA, and Oracle's MySQL Heatwave. Lakehouse//RT is a direct competitive threat to any of these that enterprises use as a real-time serving layer bolted onto a Databricks deployment.

Analysts are cautiously optimistic but not without caveats. The problem both products address is well-documented among enterprise data teams, but analysts draw a distinction between the pain point and the specific claim Databricks is making. "Enterprises have had HTAP, streaming, cloud warehouses, and operational stores for years,

Trending
  • No trending articles

Comments

avatar

Next Reads