Why Dashboards Get Slow (and How to Fix It)

Dashboards get slow because they run expensive queries against raw, row-level data every time someone opens them, instead of reading from data that's already been aggregated. The fix is almost never a bigger warehouse — it's pre-aggregating the numbers the dashboard actually needs and querying that instead.

What actually makes a dashboard slow?

Three things dominate: querying raw, unaggregated tables instead of pre-summarized ones; firing a separate query per chart instead of one shared query; and joining large fact tables at query time instead of pre-joining them in a nightly job. Any one of these turns a sub-second dashboard into a 10-30 second one once the underlying tables reach millions of rows.

Should a dashboard use an extract or a live query?

Use an extract (a cached, pre-computed snapshot) unless the dashboard genuinely needs to reflect data less than an hour old, like an operations or fraud-monitoring view. Live queries recompute the full result set on every page load and every filter change, which is fine at small data volumes and unbearable at large ones.

	Live query	Extract / cached
Freshness	Real-time	As of last refresh (e.g. hourly, nightly)
Load time	Depends on source system load	Fast and predictable
Source system impact	Every viewer hits the database	One scheduled job hits the database
Best for	Ops monitoring, fraud alerts	Executive, sales, marketing reporting

What is pre-aggregation and why does it help so much?

Pre-aggregation means computing the sums, counts, and averages the dashboard needs ahead of time — in a scheduled job — and storing the result in a small summary table, so the dashboard queries thousands of rows instead of millions. A "revenue by day by region" chart doesn't need to scan every order row at view time if a nightly job already rolled orders up to daily-by-region totals.

-- Instead of the dashboard running this on every page load:
SELECT region, DATE(order_date) AS day, SUM(amount) AS revenue
FROM orders
GROUP BY region, DATE(order_date);

-- Pre-aggregate it nightly into a summary table:
CREATE TABLE daily_revenue_by_region AS
SELECT region, DATE(order_date) AS day, SUM(amount) AS revenue
FROM orders
GROUP BY region, DATE(order_date);

-- Then the dashboard just does:
SELECT * FROM daily_revenue_by_region WHERE day >= CURRENT_DATE - 30;

The pre-aggregated query above touches a table with one row per region per day instead of one row per order, so it stays fast even as order volume grows into the tens of millions.

How many queries should one dashboard fire?

As few as possible — ideally one shared query per data source that every chart on the page reads from, rather than one query per chart. A dashboard with 8 charts firing 8 independent queries against the same table multiplies load on the source system by 8 for no analytical benefit.

Common mistakes

• Building charts directly against transactional (OLTP) tables meant for the application, not analytics.
• Setting live-refresh on a dashboard that's only ever checked once a day, adding load with no viewer benefit.
• No index or partition on the date column used for filtering, so every date-range filter triggers a full table scan.
• Stacking calculated fields on calculated fields inside the BI tool instead of resolving the logic once in the warehouse.