If you have ever pointed a dashboard or a customer-facing app at a Databricks SQL warehouse and watched the spinner tick past one second, Lakehouse Real-Time is the feature you have been waiting for. Now in Beta as of June 30, 2026, Lakehouse//RT is a new serverless SQL warehouse type built for low-latency, high-concurrency workloads against Unity Catalog tables. The promise is sub-second SELECT queries for hundreds to thousands of concurrent users.
Lakehouse//RT is a purpose-built read-only serving engine. Databricks positioned it explicitly for serving analytical data to custom applications, operational analytics, and BI dashboards in its June 2026 release notes. The feature is in active Beta, meaning performance characteristics and the supported feature set will change before general availability.
What is Lakehouse//RT and how is it different from a serverless SQL warehouse?
Lakehouse//RT is a distinct warehouse type, not a configuration flag on an existing SQL warehouse. You create it from the same SQL Warehouses UI, but it shows up as "Real-Time" alongside "Serverless" and "Pro." You cannot upgrade an existing SQL warehouse to Lakehouse//RT, and you cannot downgrade a Lakehouse//RT warehouse back. It is its own animal.
The engine is optimized for point lookups and short aggregations against well-clustered Unity Catalog managed tables. It supports Delta Lake and Apache Iceberg managed tables, materialized views, streaming tables, and metric views. For best performance, Databricks recommends managed tables with predictive optimization and liquid clustering enabled, because the engine depends on good data layout to hit sub-second latency.
| Dimension | Lakehouse//RT | Serverless SQL | Pro SQL |
|---|---|---|---|
| Target latency | Sub-second | Seconds | Seconds to minutes |
| Concurrency target | Hundreds to thousands | Tens to hundreds | Tens |
| Query types | SELECT only | Full DDL, DML, SELECT | Full DDL, DML, SELECT |
| Connectivity | Statement Execution API only | Thrift and Statement Execution API | Thrift and Statement Execution API |
| Table support | UC managed, MVs, streaming tables, metric views | All Unity Catalog tables | All Unity Catalog tables |
| Billing SKU | Lakehouse_Serverless | Serverless_SQL | Classic_SQL |
The connectivity distinction is the one most likely to bite you. Lakehouse//RT rejects any connection that does not use the Statement Execution API. If your BI tool or driver connects via the legacy Thrift protocol, it receives a 501 error. That rules out tools that have not adopted the Statement Execution API, which includes some older JDBC drivers and legacy BI connectors. You need to verify your client stack before planning a migration.
The chart below shows how Databricks positions the three warehouse types against each other on the two dimensions that matter most for serving workloads.
Lakehouse//RT sits in a different quadrant from both serverless SQL and Pro SQL: sub-second target latency with thousands of concurrent users, compared to seconds and tens for the other two.
How do you enable and create a Lakehouse//RT warehouse?
The feature is gated behind a workspace-level preview. A workspace admin enables it by navigating to the workspace menu in the top-right corner, selecting Previews, searching for "Lakehouse RT," and toggling it on. Until that toggle is flipped, the Real-Time warehouse type does not appear in the creation flow.
Once enabled, creating a warehouse is straightforward:
- Go to Compute, then SQL Warehouses, then Create SQL Warehouse.
- Select Real-Time as the warehouse type.
- Choose a size: Small, Medium, Large, or X-Large.
- Name the warehouse and click Create.
Permissions work the same as any SQL warehouse. Grant Can use, Can monitor, or Can manage to users and groups.
For connecting, the Statement Execution API is your only path. A basic request looks like:
curl -X POST \
https://<workspace-url>/api/2.0/sql/statements \
-H "Authorization: Bearer <token>" \
-H "Content-Type: application/json" \
-d '{
"warehouse_id": "<rt-warehouse-id>",
"statement": "SELECT count(*) FROM catalog.schema.table WHERE dt = '\''2026-06-30'\''",
"format": "ARRAY"
}'No Thrift, no JDBC URL with the old protocol. If your application or BI tool cannot speak the Statement Execution API, Lakehouse//RT is invisible to it.
What can it actually run, and what breaks?
Lakehouse//RT runs ANSI-compliant SELECT queries. That is the full scope. Write commands, DDL, DML, and ETL operations are all unsupported. If a query uses an unsupported feature, the engine returns an error naming the feature and telling you to use a serverless SQL warehouse instead.
Several specific capabilities are off the table:
- The GEOGRAPHY and GEOMETRY data types are not supported.
- AI functions are not supported.
- Python UDFs are not supported.
- Spatial SQL functions and XPath and XML functions are not supported.
On the governance side, the picture is better. Lakehouse//RT does support attribute-based access control, including row-level security and column masking. Your serving queries respect the same Unity Catalog policies as your batch workloads, without duplicating policy logic in the application layer.
The practical implication: if your dashboard or application query calls a Python UDF to enrich results, or uses an AI function to classify a row on the fly, that query will fail on Lakehouse//RT. You need to move that logic upstream into a materialized view or a streaming table so the computed result is already on disk when the serving query runs.
You can monitor Lakehouse//RT queries the same way you monitor any SQL warehouse query. Queries appear in the query history UI and the query history system table. You can open a Lakehouse//RT query in the query history UI to view its profile. The monitoring page for each warehouse shows query throughput, queued queries, and query history.
How does the billing work?
Lakehouse//RT is serverless, so you pay for compute on demand with no idle clusters to shut down. Usage appears in the billing system tables under the SKU name Lakehouse_Serverless. That is the same billing surface you already use to track serverless SQL spend, but with a distinct SKU so you can separate Lakehouse//RT costs from your standard serverless warehouse costs.
Databricks has not published specific per-DBU pricing for Lakehouse//RT in the Beta documentation. The four sizes, Small through X-Large, follow the same naming convention as other SQL warehouses, but the Beta status means pricing and performance characteristics are subject to change. Treat any cost estimates as provisional until the feature reaches GA.
The cost question really comes down to concurrency. If you are currently running a Pro SQL warehouse sized for peak concurrency and it sits idle for 16 hours a day, Lakehouse//RT could lower your bill by serving the same traffic from a serverless pool that scales to zero. If your workload is a handful of analysts running ad hoc queries, you will not see a meaningful difference because your existing serverless warehouse already handles that pattern.
For more on how the serving layer connects to the rest of the platform, see our Databricks Data Intelligence Platform overview, which covers how Unity Catalog, Mosaic AI, and the compute layers fit together.
When is Lakehouse//RT the wrong choice?
If your workload is write-heavy, uses ETL, or depends on UDFs and AI functions, Lakehouse//RT is the wrong tool. It is a serving engine. Treating it as a general-purpose warehouse will produce errors and frustration.
It is also wrong if your client stack relies on Thrift. The Statement Execution API restriction is a hard limit. Some BI tools and application frameworks have not yet adopted it, and until they do, they cannot connect. Before you plan a migration, inventory every client that touches your SQL warehouse and confirm each one can use the Statement Execution API.
Finally, it is wrong for exploratory analytics. If your users run complex multi-table joins with subqueries and window functions in an ad hoc fashion, the engine is not optimized for that. The best-practices guidance from Databricks is explicit: validate that your queries run in a few seconds on a serverless SQL warehouse first, then move them to Lakehouse//RT. If a query takes 10 seconds on serverless, it will not take 500 milliseconds on Lakehouse//RT.
What should you do before moving a workload over?
Start with the queries, not the warehouse. Pick the dashboard or application endpoint you want to accelerate and audit its SQL. Confirm every statement is a pure SELECT with no unsupported functions or data types. Run each query on a serverless SQL warehouse and verify it completes in a few seconds.
Then look at your data layout. The single biggest factor in hitting sub-second latency is using Unity Catalog managed tables with predictive optimization and liquid clustering. If your tables are external, unclustered, or large with no partition pruning, the engine cannot help you. Materialized views that pre-aggregate complex joins are your friend here.
A checklist before you flip the switch:
- Enable the Lakehouse RT preview in your workspace under Previews.
- Confirm your client uses the Statement Execution API, not Thrift.
- Validate target queries run in seconds on serverless SQL.
- Move computed columns and UDF logic into materialized views or streaming tables.
- Ensure tables are managed with liquid clustering and predictive optimization.
- Filter early with WHERE clauses, select only needed columns, and lean on aggregations.
- Check that row-level security and column masking policies carry over correctly.
Databricks also recommends checking that your workloads are ANSI compliant and avoiding the unsupported statements, functions, and data types listed in the Limitations section of the Lakehouse Real-Time documentation. When a query hits an unsupported feature, the error message names it.
The real test is your p99
Lakehouse//RT is a bet that a purpose-built read-only serving engine can beat a general-purpose SQL warehouse on latency and concurrency for the specific workload of serving analytical data to applications. The Beta restrictions are real: SELECT only, Statement Execution API only, no UDFs, no AI functions, no spatial types. But if you have a dashboard that thousands of users hit every minute, or a customer-facing app that needs fresh lakehouse data in under a second, this is the first Databricks warehouse type built for that job. Enable the preview, point your fastest dashboard at it, and measure your p99 latency at peak concurrency against what your current serverless warehouse delivers.
Sources
- Databricks - Lakehouse Real-Time documentation
- Databricks - June 2026 release notes
- Databricks - Real-Time Lakehouse product page
