Snowflake Query & Workload Performance
Investigate expensive analytical workloads by connecting query history, pruning, spills, clustering, concurrency and warehouse behavior to cost and latency.
Analytical capability
Query history
Rank expensive or regressed workload patterns rather than optimizing one isolated SQL statement.
Pruning / clustering
Review whether data layout and query predicates are creating avoidable scan amplification.
Warehouse economics
Separate query inefficiency from concurrency/capacity needs before simply scaling warehouse size.
Start from query history, not one query
SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY keeps a year of queries, with up to 45 minutes of latency. Grouping by query_parameterized_hash, warehouse and query_tag shows which workload patterns account for elapsed time and warehouse use. The columns that usually explain a slow or expensive pattern:
| Columns | What they suggest |
|---|---|
partitions_scanned vs partitions_total | Whether predicates prune micro-partitions. Scanning most partitions for a narrow question points to data layout or predicate shape. |
bytes_spilled_to_local_storage, bytes_spilled_to_remote_storage | Memory pressure in joins, sorts or aggregations. Remote spilling is the expensive case. |
queued_overload_time | Queries waiting because the warehouse is busy: a concurrency problem, not a single-query problem. |
queued_provisioning_time | Time waiting for a warehouse to start or resume. |
compilation_time vs execution_time | Whether time goes to planning very large or generated SQL or to running it. |
Workload isolation and concurrency
A common pattern is one warehouse serving dashboards, ad hoc analysis, scheduled transformations and loads. A heavy batch job then shows up as queueing on interactive queries, and the usual response is a bigger warehouse for everyone.
- Separate warehouses by workload when the patterns have different latency needs or schedules. Each can then be sized, suspended and attributed on its own.
- Size versus clusters. A larger warehouse helps individual heavy queries and spills. Multi-cluster warehouses (Enterprise Edition) add clusters for concurrency; Snowflake's documentation describes them as less useful for speeding up a single slow query. The Standard scaling policy favors avoiding queues, Economy favors credits.
- Check before scaling. If
queued_overload_timeis low and the slow pattern scans most partitions, more compute will cost more without fixing the cause. - Gen2 or Adaptive? Decide from idle credits, spills, pruning and queuing in your own history; see Snowflake Gen2 vs Adaptive warehouses.
From Snowflake's documentation for QUERY_HISTORY and multi-cluster warehouses, checked 13 October 2026.
Production evidence
Have a Snowflake workload you want reviewed?
Start with query history, warehouse configuration and the cost or latency symptom. Scope is agreed once the problem and evidence are clear.
Prefer to talk first? Book a 20-minute triage call.