A dashboard that used to load in seconds now takes minutes, and the first instinct is to give the warehouse more compute. Sometimes that works. Often it only raises the bill while the real cause, an inefficient query or a poorly laid out table, stays in place. This guide gives a repeatable order of investigation, so you diagnose before you spend.

Step One: Establish What “Slow” Means

Vague complaints produce vague fixes. Before changing anything, gather facts:

• Is one query slow, or is everything slow?
• Did it get slower gradually, or suddenly after a change?
• Is it slow all the time, or only at certain hours?
• How does it compare with the same query run alone?

Gradual slowing usually points to data growth. A sudden change suggests a code change, a schema change or a different query plan. Slowness only at busy times suggests contention rather than a bad query.

Step Two: Read the Query Profile

Most cloud warehouses expose a query profile or execution plan showing where time went. Learn where yours is, because it replaces guessing. Look for the stage that dominates the runtime and ask what it is doing: scanning, joining, sorting, aggregating or waiting.

Exact terminology and tooling differ between platforms, so check your provider’s current documentation for how to read its plans.

Step Three: Check How Much Data Is Scanned

The most common cause of slow analytical queries is reading far more data than needed. Warning signs include selecting every column when only a few are used, filtering on fields that the table layout cannot prune, and reading entire history for a question about last week.

Fixes tend to be simple: select only needed columns, filter early on partition or clustering fields where your platform supports them, and avoid wrapping filter columns in functions that prevent pruning.

Step Four: Examine Joins

Joins are the second great source of slowness. Look for:

• Accidental row multiplication. A join on a non-unique key can multiply rows. If the output row count is far larger than expected, check the join keys.
• Joining before filtering. Reduce each input first when the engine does not do it for you.
• Large-to-large joins that could be pre-aggregated or pre-joined into a summary table.

Step Five: Consider Table Design

If scans and joins look reasonable, the table layout may be working against you. Depending on the platform, relevant choices include how data is partitioned or clustered, how it is sorted, and how it is distributed across nodes. Small, fragmented files in lake-style tables can also slow reads and may need compaction.

Step Six: Rule Out Contention

When the same query is fast alone and slow at peak, the problem may be concurrency. Many users or jobs share the same compute, and queries queue. Options include separating workloads (for example, loading jobs apart from dashboards), scheduling heavy jobs off-peak, or scaling compute for specific workloads. Scaling is a legitimate fix here, but only after you have confirmed contention is the cause.

A Diagnostic Table

Symptom	Likely cause	First thing to try
Slow only on large history ranges	Excess data scanned	Filter on partition or date fields
Output has far more rows than expected	Row multiplication in a join	Check join key uniqueness
Slow only at peak hours	Concurrency and queuing	Separate or schedule workloads
Slowed gradually over months	Data growth, outdated design	Review table layout and summaries
Sudden slowdown after a release	Changed query or schema	Compare plans before and after
Repeated identical dashboard queries	No reuse of results	Use result caching or summary tables

Reduce Work Instead of Adding Compute

Once you find the cause, favor fixes that reduce work. Summary or aggregate tables turn repeated heavy calculations into cheap lookups. Materialized or pre-computed views serve dashboards without re-scanning raw data on every refresh. Incremental transformations process only new data instead of rebuilding history nightly.

Adding compute remains a valid tool, especially for contention, but it should follow diagnosis rather than replace it.

Keep the Fix From Regressing

A fix that nobody records tends to be undone. Keep a short note of what was slow, what the cause was and what changed. If your team uses version control for SQL, add a comment or commit message that explains the reasoning. Consider monitoring the runtime of your most important queries so you notice drift before users complain.

A Realistic Example

Imagine a hypothetical operations dashboard that began taking minutes to load. The team compares the plan with an older one and sees that the scan stage dominates. The query selects all columns from a large events table and filters on a timestamp wrapped in a function, which prevents pruning. They rewrite the filter to compare the raw timestamp against a date range, select only the six columns the dashboard needs, and move a repeated daily aggregation into a summary table refreshed on a schedule. The dashboard returns to loading quickly without any change to compute size, and the team documents the pattern for the next analyst who builds a similar report.

Frequently Asked Questions

Should I scale up the warehouse as soon as queries slow down? Not before diagnosing. Scaling helps with contention or genuinely heavy workloads, but it can mask an inefficient query and raise costs indefinitely.

Why does the same query vary in runtime? Caching, concurrent load, data changes and background maintenance can all affect it. Compare runs under similar conditions before drawing conclusions.

Are indexes the answer in a cloud warehouse? Many cloud warehouses do not use traditional indexes in the way transactional databases do and rely on partitioning, clustering and columnar storage instead. Check your platform’s documentation for its specific mechanisms.

How can I find the worst queries? Most platforms provide query history with runtimes and resource usage. Sort by total time consumed, not just single-run duration, since a moderately slow query run thousands of times can cost more than one very slow query.

Is SELECT star really that harmful? In columnar systems it usually forces reading every column, which increases scanned data and cost. Selecting only what you need is a cheap, consistent improvement.

Next Step

Take the slowest dashboard query in your environment and open its profile. Identify the dominant stage, check scanned data against what the question actually requires, and make one change at a time. Record the before and after runtime so the improvement is visible.