Lakehouse RT: Millisecond Performance on Delta Without Leaving the Lakehouse
- Miguel Diaz
- Jun 16, 2026
- 10 Mins read
- Databricks
Your lakehouse stores all your data. Your streaming pipelines keep it updated in seconds. But when the product team asks for a dashboard that loads in 50ms with 500 concurrent users, your Data Engineers do what everyone does: spin up a separate ClickHouse, sync the data, duplicate the schema, and pay another invoice.
That pattern — repeated across dozens of companies — creates three real problems: duplicated data that drifts out of sync, fragmented governance across two systems, and double infrastructure costs. Lakehouse//RT exists to cut that cycle at the root.
What is Lakehouse//RT?
Real milliseconds
Millisecond performance at high concurrency, not just in isolated queries
Native Delta/Iceberg
Reads directly from Unity Catalog. No copies, no sync ETLs
Full vectorized engine
Rebuilt native engine, Photon-aligned for an end-to-end vectorized pipeline
Unified governance
Unity Catalog enforces the same ACLs, lineage, and audit across all your data
Lakehouse//RT is a new warehouse type that appears in the Databricks SQL warehouse picker, alongside SQL Classic, Pro, and Serverless. Unlike its siblings — optimized for batch analytics and ad-hoc workloads — Lakehouse//RT is built from scratch for millisecond latency at high concurrency.
The key technical difference: its execution engine was rebuilt natively and aligned with Photon to create a fully vectorized pipeline, end-to-end. It’s not an extension of an existing warehouse — it’s a different architecture for a different use case.
It entered Gated Beta at DAIS 2026 and is available on AWS, Azure, and GCP where SQL Serverless runs (GovCloud is not yet supported).
The problem: the fragmented stack everyone builds today
The architecture every team eventually builds
Users need millisecond latency
Operational dashboards, embedded analytics apps, and observability tools demand sub-100ms responses. A traditional analytical lakehouse responds in seconds — too slow for these workloads.
The typical solution: bolt on another system
Teams end up adding ClickHouse, StarRocks, Snowflake, Fabric RTI, or BigQuery on top of the lakehouse to serve fast queries. The result: duplicated data, fragmented governance, and a second invoice.
ClickHouse
Parallel stack + data sync
StarRocks
Duplicated ingestion + separate ops
Snowflake
General-purpose, not ms-optimized
Fabric RTI
Separate ecosystem, outside lakehouse
The real cost: not just the extra invoice. It’s the sync pipeline you have to maintain, the data lag between systems, the double permission configuration, and the risk of inconsistencies in production. Lakehouse//RT eliminates all of that — millisecond queries directly where your data already lives.
How it works: the new warehouse picker
Databricks SQL warehouse types
SQL Classic
Standard analytics in your cloud account. Startup in minutes.
SQL Pro
Photon + Predictive IO. For intensive analytical workloads.
SQL Serverless
~2–6s startup. IWM + Photon. High analytical concurrency.
Lakehouse//RT NEW
Rebuilt vectorized engine. Photon-aligned. Native Delta/Iceberg. True high concurrency.
The engine: end-to-end vectorized pipeline
Unlike traditional analytical warehouses that have row-by-row execution bottlenecks, Lakehouse//RT keeps the entire pipeline in columnar vectorized format: from reading Parquet/Delta in storage all the way to result delivery. Combined with Photon alignment, this is what enables millisecond latency without sacrificing the ability to read directly from the lakehouse.
Three use cases that justify it
Operational analytics
Operations dashboards, real-time KPIs, business metrics with fresh data. Applications that need to query the current state of operations with sub-100ms latency and tens or hundreds of concurrent users.
Replaces the ClickHouse stacks spun up for “just this one operational dashboard.”
Embedded BI serving
Analytics embedded in products — where the end user is not an internal analyst but a product customer. These contexts require instant loads and high simultaneous concurrency. AI/BI today; Power BI and Tableau via JDBC+ODBC coming soon.
The use case where “slow dashboards for users” is solved by adding more hardware — until now.
Observability & monitoring
Internal observability platforms, data-driven alert systems, real-time data quality monitoring. Cases where you need to correlate log events, workload metrics, and table data with minimal latency.
Natural synergy with Genie ZeroOps for real-time failure correlation.
What Lakehouse//RT removes from your architecture
Before vs. after Lakehouse//RT
WITHOUT Lakehouse//RT
Data duplicated between lakehouse and serving layer
Fragmented governance: two ACL systems
Second bill (ClickHouse, StarRocks, etc.)
Sync pipeline that breaks and drifts
Separate ops for two distinct platforms
WITH Lakehouse//RT
Single copy: Delta/Iceberg in Unity Catalog
Unified governance: Unity Catalog applies everywhere
One invoice: the warehouse is part of Databricks
No sync pipelines to maintain
Single operations and monitoring plane
Availability and BI tools
Availability by cloud
Lakehouse//RT is in Gated Beta on AWS and Azure. Also available on GCP where SQL Serverless runs. GovCloud is not yet supported — dates for regulated environments will be announced on the official roadmap.
Supported BI tools
Available today: Databricks AI/BI (Genie + native dashboards). Coming soon: Power BI and Tableau will connect via JDBC+ODBC, enabling the same millisecond performance from existing BI tools.
Frequently asked questions
Lakehouse//RT closes one of the last gaps of the modern lakehouse: serving speed for concurrent users. Until now, the answer to “I need dashboards that load in milliseconds” was always “spin up another system.” With Lakehouse//RT, that answer changes to “pick a different warehouse type in the same picker.”
For teams currently maintaining ClickHouse or StarRocks stacks synchronized with Databricks, this is the product they’ve been waiting for: the same lakehouse, the same data, the same permissions — at the speed production applications demand.