Dashboard performance problems rarely come from a single place. Slowness on a Databricks AI/BI dashboard usually reflects the combined effect of dashboard design, warehouse concurrency and caching, and how data is laid out in the lakehouse. Optimising just one layer – the SQL, the compute size or the table layout – often produces a partial win while the dashboard still feels slow or unpredictable under real use. This article, the first in a series, takes an end-to-end view of AI/BI performance, following an interaction from the browser through the orchestration layer, into Databricks SQL and down to file scanning in the lakehouse, and covers the first practices for keeping dashboards fast.
The anatomy of a dashboard refresh
Optimisation starts with understanding what happens when a user opens a dashboard or changes a filter, because a single click sets off a chain reaction across several layers. A misconfiguration in any one of them shows up as lag for the user.
At the browser, or client side, small datasets are handled locally. For results under roughly 100,000 rows and under 100 MB, the browser acts as a local engine, applying field filters and cross-chart interactions instantly in memory without returning to the warehouse. Once a dataset exceeds those limits, each interaction has to go back to the SQL warehouse, which is far slower and more costly.
At the dashboard-design, or orchestration, layer, the AI/BI service decides which queries to fire. A single-page design sends every widget’s query at once, creating a large concurrency spike, whereas a multi-page design requests data only for the visible tab, reducing the load on compute. At the engine layer, the Databricks SQL warehouse – ideally serverless – receives that burst and checks its several caching layers to decide whether results can be reused or must be recomputed. Without understanding these layers, optimisation becomes guesswork that often just shifts cost or latency from one place to another.
Optimisation 1: Organise the dashboard into pages
Every visible tile is a potential trigger: it runs on first load and can run again when filters or parameters change, on refresh, and when a user returns to a page. Splitting a dashboard into multiple pages, or tabs, limits those re-executions to the active page. Grouping visuals into pages that follow user intent – for example Overview, then Investigate, then Deep Dive – means only the current page executes. This shapes concurrency into smaller bursts, reduces head-of-line blocking where one heavy query delays others, and increases cache hit rates for repeated, deterministic queries.
Optimisation 2: Shape the “first paint” with smart defaults
The first thing a user sees, sometimes called the first paint, sets the tone for perceived performance. Choosing sensible default filter values and parameters so the initial view queries a smaller, bounded slice of data – rather than scanning everything on load – makes the dashboard feel responsive from the outset. Parameters that reduce the dataset early, before deeper filtering is applied, are especially effective when a dataset might otherwise exceed the browser-side limits, because they cut how much the warehouse has to read up front.
Limitations and what to watch
These practices improve responsiveness but are not a substitute for right-sizing the underlying data and compute. The 100,000-row and 100 MB browser thresholds are specific to how AI/BI dashboards behave and can change, so current Databricks documentation should be checked rather than assuming fixed numbers. Client-side filtering is fast precisely because the dataset is small; pushing large datasets to the browser to avoid warehouse round-trips can instead slow the client or hit those limits. Multi-page layouts help concurrency but should still map to how people actually use the dashboard, and aggressive default filters must not hide data users expect to see. As always, changes should be measured against a clear goal rather than applied blindly, since an improvement at one layer can move the bottleneck to another. Teams optimising the broader platform may also find value in using system tables for observability and tuning high-QPS workloads. The full checklist is available on the Databricks community blog and the dashboard caching documentation.
