The Serving Tier Problem
For years the standard enterprise pattern has been a split. The lakehouse holds the governed analytical data, and a separate low-latency serving system, often a key-value store or a specialized OLAP database, holds a copy shaped for millisecond reads. That split exists because analytical engines were built for throughput on large scans, not for thousands of concurrent point queries answered in ten milliseconds. The cost is duplicated data, extra pipelines to keep the copy fresh, and governance that fragments the moment data leaves the lakehouse.
Databricks launched Lakehouse//RT on June 16, 2026 to attack exactly that split. The claim is that you can serve real-time queries directly on governed Delta Lake and Apache Iceberg tables, with no proprietary formats, no data copies, and no separate ingestion pipeline. CEO Ali Ghodsi framed it as filling a gap in the platform: "Lakehouse//RT completes the engine spectrum, providing the millisecond speed layer that people want and agents require." The agent framing is deliberate, because autonomous systems generate far more concurrent queries than dashboards ever did.
Reyden and the Numbers Behind It
The engine underneath is new and named Reyden. Databricks describes it as built from the ground up for high concurrency and low latency, using a fully asynchronous execution model. The headline figures are aggressive. Databricks reports response times of 10 milliseconds on smaller datasets and sub-100 milliseconds on larger ones, throughput of 12,000 queries per second at sub-100 millisecond latency, and up to 16 times better performance than existing real-time serving stacks the company benchmarked against.
We treat vendor benchmarks with the usual caution, because the datasets and query shapes are chosen by the vendor. What raises the credibility here is that the numbers are specific rather than vague, and they come with named customer corroboration. Chris Kopek, Head of Data Platforms at Cisco, said the team is "seeing millisecond performance on live data with 5x improvement in response time." Kayvon Raphael, a Senior Director of Engineering at Magnite, reported "sub-200 millisecond performance on our core dashboard queries, consistently." Real customers citing their own numbers is worth more than a benchmark chart.
Open Tables Are the Real Bet
The architectural detail that matters most is that Reyden runs on open table formats. Queries execute natively on governed Delta Lake and Apache Iceberg tables, with all access flowing through Unity Catalog's governance framework. There is no proprietary serving format to load into and no separate copy to secure and reconcile. That is the difference between this and the specialized serving databases it aims to replace, which typically require you to move data into their own format and manage governance twice.
This design choice tracks the broader 2026 pattern of engines competing on speed while agreeing on Iceberg as the common substrate. Snowflake, Databricks, and the open-source projects have all converged on open tables as the interoperability layer, and Lakehouse//RT extends that convergence into the low-latency tier that was previously a proprietary island. For architects, the appeal is a single governed copy of data serving both the overnight report and the ten-millisecond agent lookup. That is a genuine simplification if the performance holds in your workloads.
What It Changes for Architecture and Cost
If Lakehouse//RT delivers on live workloads, the immediate question is whether you still need the separate serving database in your stack. Every duplicated system carries a triple cost: the infrastructure itself, the pipelines that keep it synchronized, and the engineering time spent reconciling governance across two homes for the same data. Collapsing that tier back onto the lakehouse removes all three, and it removes an entire class of freshness bugs where the serving copy lags the source of truth.
There is a counterweight to name. Consolidating your low-latency serving onto Databricks deepens dependence on a single platform, and the beta label means this is not yet a decision to bet a production SLA on. The honest posture is to run a bounded proof of concept against your actual query mix and concurrency, measure the latency and the cost per query, and compare both against the serving system you run today. The prize is a simpler architecture, and simpler architectures are only worth it when the performance is genuinely there.
The Agent Angle Is Not Marketing Fluff
The repeated emphasis on agents is easy to dismiss as positioning, and we think that would be a mistake here. A human analyst refreshes a dashboard a few times an hour. An autonomous agent evaluating options can fire thousands of point queries per minute as it explores a decision space, and it needs each answer back in milliseconds to stay responsive. The concurrency and latency profile of agent workloads looks nothing like the reporting workloads most serving tiers were sized for.
That is why Reyden's asynchronous, high-concurrency design and the 12,000 queries per second figure read as aimed at a real emerging requirement rather than a benchmark flex. As enterprises move agents from pilots into production, the data layer underneath them has to answer at machine speed and machine volume. Lakehouse//RT is Databricks arguing that the same governed lakehouse can serve that traffic, which, if true, saves teams from standing up yet another specialized system just to keep their agents fast.
How to Evaluate It Without the Hype
Bring your own workload to the evaluation. Vendor benchmarks tell you what the engine can do on data the vendor chose, and only your query mix, concurrency, and data volumes tell you what it will do for you. Instrument a proof of concept that mirrors your real serving patterns, including the worst-case concurrency you expect from agents, and record latency at the tail rather than the average, because the ninety-ninth percentile is what breaks user trust.
Then do the full-cost comparison honestly. Weigh the Databricks compute cost against everything the separate serving tier costs you today, including the pipelines and the engineering hours spent keeping two systems in sync. Factor in the governance simplification of a single copy under Unity Catalog, which has real value even though it is harder to put a number on. If the latency holds and the total cost lands lower, consolidating is the right call. If it does not, keeping the specialized tier is a defensible decision, not a failure.
