What workload characteristics make Lakehouse//RT a good or poor fit?

Summary

• What it is. Databricks Lakehouse//RT is a real-time serving SQL warehouse type built for low-latency, high-concurrency analytical queries on live data already in the lakehouse. It is currently in beta and in active development.
• Good fit. Read-only (SELECT) analytical serving: short, interactive, selective queries that need sub-second responses for hundreds to thousands of concurrent users on fresh Unity Catalog data — operational analytics, high-concurrency BI dashboards, customer-facing analytical apps, and observability and monitoring.
• Poor fit. ETL and data transformation, write operations (INSERT, UPDATE, DELETE, MERGE), large full-table scans, and complex queries that need broad SQL features or run long — these belong on standard SQL warehouse types or Lakeflow pipelines.
• Data requirements. Reads Unity Catalog managed tables in Delta Lake or Apache Iceberg format directly, so real-time serving runs on the same governed data — no data movement.
• A quick test. A workload is a candidate if it is read-only, runs quickly on a serverless SQL warehouse today, and uses Unity Catalog managed tables.

What workload characteristics make Lakehouse//RT a good or poor fit?

Databricks Lakehouse//RT is a serverless, real-time serving SQL warehouse type. Its sweet spot is low-latency, high-concurrency analytical serving: fast, sub-second queries on fresh data that already lives in the lakehouse, served to many concurrent users or applications. It is currently in beta and in active development, so its supported feature set and performance characteristics may change before general availability. See Real-time SQL warehouses, Performance differences between SQL warehouse types, and the launch blog Introducing Lakehouse//RT.

Workload characteristics that are a good fit

Lakehouse//RT is a good fit when the workload is analytical serving rather than data processing:

• Read-only queries. It serves SELECT queries — the workload should not depend on the warehouse performing writes.
• Short, interactive, selective queries. Queries that return quickly, filter early with WHERE clauses, select only the columns needed, and scan a modest amount of data rather than performing large full-table scans.
• Sub-second latency at high concurrency. Workloads that need near-instant responses for hundreds to thousands of concurrent users or requests.
• Fresh data already in the lakehouse. It reads Unity Catalog managed tables in Delta Lake or Apache Iceberg format directly, so there is no separate copy of the data to move or maintain.

Documented use cases include operational analytics, BI dashboards and serving layers with high concurrency, customer-facing analytical applications, and observability and monitoring.

Workload characteristics that are a poor fit

Lakehouse//RT is not designed for data processing or heavy, long-running analytics. Consider a standard SQL warehouse type or a Lakeflow pipeline instead when the workload involves:

• Writes and data modification. INSERT, UPDATE, DELETE, MERGE, and similar operations — Lakehouse//RT serves SELECT queries only.
• ETL and data transformation. Building and refreshing tables, and data exploration, are better suited to standard SQL warehouses and declarative pipelines.
• Large scans and long-running queries. Queries that read large volumes of data, run long, or need broad SQL feature support and complex joins, subqueries, and window functions that exceed low-latency thresholds.

Standard SQL warehouse types remain the recommended choice for dashboards where a few seconds of response time is acceptable, for ETL, and for complex analytical queries; Lakehouse//RT targets the highly interactive experiences that need near-instant loading.

How to qualify a workload

A practical test: a workload is a Lakehouse//RT candidate if it (1) uses read-only operations, (2) already runs quickly on a serverless SQL warehouse, and (3) reads Unity Catalog managed tables. Clustering the underlying tables for the workload's access patterns and using materialized views for pre-aggregated data help keep latencies low.

Getting started

• Read Real-time SQL warehouses to understand what Lakehouse//RT is and how it serves queries.
• Review Performance differences between SQL warehouse types to see where a real-time warehouse fits alongside other warehouse types.
• Read the launch blog Introducing Lakehouse//RT: real-time performance on the unified lakehouse.

FAQs

What workloads is Lakehouse//RT best suited for?

Read-only, low-latency, high-concurrency analytical serving on fresh Unity Catalog data: operational analytics, high-concurrency BI dashboards and serving layers, customer-facing analytical applications, and observability and monitoring.

What workloads are a poor fit for Lakehouse//RT?

Write operations (INSERT, UPDATE, DELETE, MERGE), ETL and data transformation, data exploration, large full-table scans, and long-running or complex queries that need broad SQL feature support — those belong on standard SQL warehouse types or Lakeflow pipelines.

How do I know if my workload qualifies?

Confirm it is read-only, already runs quickly on a serverless SQL warehouse, and uses Unity Catalog managed tables. Well-clustered tables and materialized views help keep queries in the sub-second range.

Does Lakehouse//RT require moving data into a separate system?

No. It reads Unity Catalog managed tables in Delta Lake or Apache Iceberg format directly, so there is no separate copy of the data to move or maintain.

Is Lakehouse//RT generally available?

Not yet. Lakehouse//RT is currently in beta and in active development, so its supported features and performance may change before general availability.