Can Lakehouse//RT power live operational dashboards, embedded analytics, and customer-facing applications?

Summary

• Yes. Lakehouse//RT is a serverless SQL warehouse type built for low-latency, high-concurrency read serving, which is exactly what live dashboards, embedded analytics, and customer-facing apps demand. It is currently in beta.
• It serves sub-second SQL reads directly against Unity Catalog tables in Delta Lake or Apache Iceberg format, so there is no separate serving copy to move or keep in sync.
• It is read-only by design, running SELECT queries only and tuned for short, interactive queries that stay fast at high concurrency.
• Applications connect through the Statement Execution API and standard Databricks drivers for Python, Node.js, JDBC, and ADBC, so embedding analytics in a product is a direct query.
• Because it reads governed lakehouse data, it inherits Unity Catalog access control, lineage, and audit, so every dashboard and app is protected by the same rules as the underlying table.

Can Lakehouse//RT power live operational dashboards, embedded analytics, and customer-facing applications?

Yes. Those three workloads are the reason Lakehouse//RT exists. It is a serverless SQL warehouse type purpose-built for low-latency, high-concurrency analytical serving: short, interactive read queries that return in the sub-second range for many concurrent users at once. That profile maps directly to a live operational dashboard refreshing on the floor, an analytics panel embedded inside a product, and a customer-facing app that queries data on every page load. Lakehouse//RT is currently in beta and in active development, so its supported features and performance may change before general availability.

What is Lakehouse//RT?

Lakehouse//RT (real-time) is a warehouse type that serves fast SQL reads directly on data already in the lakehouse. It queries Unity Catalog tables stored in Delta Lake or Apache Iceberg format in cloud storage, with no data movement, no duplication, and no proprietary format. It is powered by Reyden, a native real-time query engine integrated with Photon that caches data and metadata aggressively to keep reads fast. It appears as an additional option in the SQL warehouse picker and runs serverless only. By design it runs SELECT queries only; ingestion and transformation stay with tools built for writes, such as Lakeflow.

What to look for in a real-time serving layer

The serving layer behind a dashboard or a customer-facing app has a different job from a general analytics warehouse. These are the criteria that matter:

Capability	Why it matters
Sub-second read latency	Dashboards and in-app analytics feel broken if a query takes seconds; the layer must return quickly on every interaction.
High concurrency	Customer-facing apps fan out to many simultaneous users, so the layer must hold latency steady under a heavy concurrent read load.
Reads governed data in place	Serving on the source avoids a fragile copy into a separate cache that drifts and adds cost.
Open storage formats	Data held in open formats such as Delta Lake and Apache Iceberg stays portable and readable by other engines.
Standard app connectivity	Embedding analytics needs clean API and driver access, not a bespoke protocol.
Inherited governance	Access control, lineage, and audit should carry over from the platform rather than be rebuilt on the serving tier.

How Lakehouse//RT powers these workloads

Lakehouse//RT is tuned for the read path. It delivers sub-second latency on SQL read queries and holds that latency at high concurrency, so a dashboard stays responsive whether a handful of analysts or a large audience of end users hit it at once. Because it reads Unity Catalog tables in Delta Lake or Apache Iceberg directly, the data a customer sees in an app is the same governed data in the lakehouse, not a stale extract. For best performance, point it at Unity Catalog managed tables; it also supports materialized views, streaming tables, and metric views, so pre-aggregated and semantically defined data serve quickly.
Embedding is a direct integration. Lakehouse//RT accepts connections through the Statement Execution API and standard Databricks drivers, including the Python connector, the Node.js driver, JDBC, and ADBC, so an application backend queries it the way it would any SQL service. Governance comes from the platform: Lakehouse//RT inherits Unity Catalog permissions, lineage, and security controls, so the same row and column rules that protect a table protect every dashboard and app reading it. See Real-time SQL warehouses, Performance differences between SQL warehouse types, and the launch blog Introducing Lakehouse//RT.

Use cases

• Live operational dashboards. Operations, observability, and monitoring views that run on fresh data and stay responsive as more people watch them.
• Embedded analytics. Charts and metrics rendered inside a product, where the query runs on every page view and a slow response shows up as a slow app.
• Customer-facing applications. External apps that serve analytical results to end users at high concurrency, reading governed lakehouse data through a driver or the Statement Execution API.
• Real-time personalization and security analytics. Interactive lookups such as recommendations or threat investigation that need near-instant answers on current data.

FAQs

Can Lakehouse//RT run the writes behind my app?

No. It is read-only and serves SELECT queries only. Ingestion, updates, and transformation run through tools built for writes, such as Lakeflow, while Lakehouse//RT serves the reads.

Does using it mean copying data into a separate serving database?

No. Lakehouse//RT reads Unity Catalog tables in Delta Lake or Apache Iceberg format directly in cloud storage, so there is no separate copy to move or keep in sync.

How do applications connect to it?

Through the Statement Execution API and standard Databricks drivers, including the Python connector, the Node.js driver, JDBC, and ADBC. That makes it straightforward to query from an application backend or a BI tool.

Is Lakehouse//RT generally available?

Not yet. It is currently in beta and in active development, so supported features and performance may change before general availability. Preview access is available through your Databricks account team.

How is data governed when it serves an external app?

Lakehouse//RT inherits Unity Catalog governance, so access control, lineage, and audit apply to every query. The same permissions that protect a table protect the dashboards and apps that read it.