Every Monday morning the sales dashboard on Databricks takes over a minute to load, while on other days it opens in seconds. The same queries run fast when you try them alone. How do you find and fix the cause?

Fast alone and slow on Monday at 9 points to queueing: everyone opens the dashboard at once and queries wait for room on the SQL warehouse. Confirm it on the warehouse's Monitoring tab (queued queries, Peak Queued Queries, scheduling time in each query's duration). The fix is more clusters at the peak, a serverless warehouse that scales quickly, and fewer, cheaper queries behind the dashboard. Only if single queries are slow too does the cluster size or the query itself need work.

1. Separate waiting from working

If running time is normal and scheduling time is long, the queries are fine. They are waiting their turn.

2. Give the peak enough clusters

• Serverless warehouse (Databricks' default advice): it predicts each query's needs, queues only when there is no room, and adds clusters quickly when waits grow. Set a maximum cluster count high enough for the peak.
• Pro or classic: these allow 10 concurrent queries per cluster and add clusters from the estimated minutes of queued work (1 cluster for 2 to 6 minutes of load), or when a query has waited 5 minutes. For a sharp Monday peak that reacts late; raise the minimum cluster count for that window, or move to serverless.
• Keep the cluster size for single-query speed: increase it only if the query profile shows spills to disk.

3. Make the dashboard ask for less

A dashboard with 15 visuals sends 15 or more queries per viewer. 40 people opening it at 9:00 is hundreds of queries at once.

• Point visuals at a small summary table or materialised view refreshed early on Monday, instead of the raw order lines.
• Remove visuals nobody reads, and share datasets between visuals where you can.
• Let the result cache work for you: identical queries over unchanged tables are answered from cache for up to 24 hours, so a refresh of the summary table at 7:00 followed by identical dashboard queries means most viewers hit the cache. Updating the underlying table invalidates it, so avoid refreshing that table during the peak.

4. Then fix any slow query

For queries slow even alone, the query profile's top operators show the cost: a scan reading the whole table because the date filter does not prune, a join multiplying rows, or a sort spilling to disk.

What interviewers want: telling queueing from slow queries using scheduling versus running time, the warehouse monitoring page and Peak Queued Queries, cluster count for concurrency against cluster size for single-query speed, and reducing the load a dashboard creates through summary tables and the result cache.