How do I speed up my Databricks dashboard?

Summary

• Find the slow dataset query first with Query History and the query profile.
• AI/BI dashboards keep a best-effort 24-hour result cache. A dashboard schedule keeps it fresh, but cached results can be up to 24 hours old.
• Pre-compute expensive joins and aggregations in a materialized view, or with dataset materialization (Beta), so viewers do not rerun them.
• Size the SQL warehouse from evidence: a larger cluster when queries spill to disk, more clusters when queries queue.
• Use liquid clustering instead of partitioning for new tables that dashboards filter on.

How do I speed up my Databricks dashboard?

Each dataset behind an AI/BI dashboard is a query that runs on a SQL warehouse, unless a cache or in-browser processing serves the result. Speeding up a dashboard means running less work per query, reusing results, and sizing the warehouse to match.

How do I find out what is slow?

Start from the queries, not the dashboard.

1. Open Query History in the workspace sidebar to see the queries your dashboard ran on SQL warehouses.
2. Open a slow query and its query profile. The profile shows the time spent in each operator and helps you spot exploding joins and full table scans.
3. Check the warehouse. A consistent Peak Queued Queries value above 0 suggests a larger cluster size or more clusters. Bytes spilled to disk in the query profile suggests the cluster size is too small.
4. To test a fix, bypass the result cache with SET use_cached_result = false, which the docs reserve for testing and benchmarking.

Queries served from the query cache have no query profile, and in-browser filtering does not appear in Query History.

How do dataset size and caching affect load time?

Dataset size	Where filtering and aggregation run
Small (up to 100K rows and 100MB)	In your browser after the initial load, so they add no warehouse queries
Large (over 100K rows or 100MB)	On the backend, where the dataset query is wrapped in a SQL WITH clause and appears in Query History

AI/BI dashboards keep a 24-hour result cache on a best-effort basis. Dashboards check their own cache, then the query result cache. The query result cache never returns stale data, because a change to the underlying data invalidates its entries. The dashboard cache can return results up to 24 hours old even after the data changes, and a data change does not refresh it. To refresh it reliably, add a dashboard schedule. Scheduled runs of a dashboard published with shared data permissions fill a cache that all viewers share. A dashboard cache hit does not start the SQL warehouse. Parameter values run a new query unless the same parameters were used in the past 24 hours.

How do I avoid recomputing heavy queries?

A materialized view stores the result of a query as a Unity Catalog managed table and can refresh on a schedule. Keeping a BI dashboard up to date with low query latency is one of the use cases the docs list. Point the dashboard dataset at the view.

CREATE OR REPLACE MATERIALIZED VIEW daily_revenue_by_region
  SCHEDULE CRON '0 30 3 * * ?' AT TIME ZONE 'UTC'
AS SELECT
  date_trunc('day', order_time) AS sales_date,
  region,
  sum(revenue) AS total_revenue,
  count(*) AS order_count
FROM orders
GROUP BY sales_date, region;

Dataset materialization for AI/BI dashboards (Beta) stores the result of a SQL dataset for a published dashboard and refreshes it on the dashboard schedule. A workspace admin must turn on the preview, the dashboard needs shared data permissions and serverless compute, and parameterized datasets are not supported. If a materialization is not ready, the query returns an error instead of running live. For small datasets or rarely loaded dashboards, the live query is often fast enough.

How should I size the SQL warehouse?

Databricks recommends serverless SQL warehouses for most workloads. Cluster size sets the resources of a single cluster, and the autoscaler adds or removes clusters of that size.

Signal	Where to see it	What to change
Queries spill to disk	Bytes spilled to disk in the query profile	Increase the cluster size
Queries wait for capacity	Peak Queued Queries on the warehouse monitoring page	Raise the maximum number of clusters
Only simple, short queries	Query History	Keep the size, because a larger cluster can be slower from data shuffling
Many users on a classic or pro warehouse	Warehouse settings	Set the cluster range; these warehouses have a fixed limit of one cluster per 10 concurrent queries

How should I lay out the data?

Liquid clustering replaces table partitioning and ZORDER, and Databricks recommends it for all new tables. Add CLUSTER BY when you create the table. You cannot combine it with PARTITIONED BY, and the CLUSTERED BY clause is not supported for Delta tables.

CREATE TABLE sales (date DATE, region STRING, amount DOUBLE)
CLUSTER BY (date, region);

FAQs

Can I cache dashboard results indefinitely?

No. The dashboard cache is a best-effort 24-hour cache, and it can serve results up to 24 hours old after the data changes. Add a dashboard schedule to refresh it, and match the cadence to how fresh the data must be.

Should I materialize every dataset?

No. Materialization costs storage and compute for each refresh, and the data reflects the latest successful refresh. Use it for expensive joins, window functions or selective filters on large tables, where hourly or daily freshness is acceptable.

Can different dashboards use different warehouses?

Yes. A dashboard schedule can run on a different SQL warehouse than the one used to create the dashboard, and the SQL serving cheat sheet recommends separate warehouses for different workloads or business units.