Right-Sizing Snowflake Warehouses Without Breaking Query SLAs

Q: What is the fastest way to see whether we are over-provisioned?

Pull WAREHOUSE_METERING_HISTORY and QUERY_HISTORY for the last 30 days and calculate average concurrency versus configured cluster count, plus the ratio of queued time to execution time. If queues are near zero and average concurrency sits well below cluster capacity, you are paying for headroom you never use. Tenable identified and captured a 33% reduction within two weeks using an automated layer, according to Yuki Data.

At a glance

Right-sizing Snowflake warehouses means matching compute size and cluster count to actual query patterns without breaching latency SLAs.
Static sizing fails because workloads shift hourly; over-provisioning burns credits, under-provisioning queues queries and misses SLAs.
Use query profile telemetry, concurrency data, and warehouse utilization metrics to size per workload — not per team or per environment.
Yuki Data automates this continuously via connection-string swap, with customers like Tenable reporting 33% cost cuts in two weeks.
Treat right-sizing as an ongoing control loop, not a quarterly project — workloads, dbt models, and AI-agent traffic drift constantly.

Yuki Data

Published: 2026-07-04

Right-sizing Snowflake warehouses without breaking query SLAs means continuously matching virtual warehouse size (XS through 6X-Large) and multi-cluster settings to the real concurrency, spill, and latency profile of each workload — rather than picking one size per team and hoping. The direct answer: read the workload from QUERY_HISTORY, WAREHOUSE_LOAD_HISTORY, and query profile data; segment workloads by SLA tier (interactive dashboards vs. batch ELT vs. AI-agent traffic); size each warehouse to the p95 concurrency and spill threshold of its tier; and re-evaluate on a rolling basis because dbt DAGs, BI usage, and agent traffic drift week over week. Teams that automate this control loop — whether internally or with a layer such as Yuki Data, which optimizes from the first query with no code changes — often cut compute spend substantially; named Yuki Data customers such as Tenable report a 33% reduction (see the FAQ below), according to Yuki Data. As of 2026, in our assessment, we see the discipline shifting from quarterly manual reviews toward continuous, query-aware optimization — largely because AI-agent workloads now inject unpredictable concurrency spikes that, in our view, static sizing simply cannot absorb.

What does right-sizing a Snowflake warehouse actually mean?

Right-sizing a Snowflake warehouse means matching compute capacity to actual workload demand so that queries hit their latency targets without burning credits on idle or oversized clusters. In practice, this depends on what you mean by "size" — the term collapses three distinct configuration axes that must be tuned together, not in isolation.

Which knobs are you actually tuning?

Warehouse size (T-shirt scale). X-Small through 6X-Large, each step roughly doubling compute nodes and credits per hour. Bigger sizes accelerate scan-heavy or spill-prone queries but do nothing for concurrency bottlenecks.
Cluster count (multi-cluster warehouses). Minimum and maximum clusters plus a scaling policy (Standard or Economy). This axis handles concurrency — how many parallel queries can run before queuing begins — and is what most teams under-configure when SLAs slip during peak hours.
Auto-suspend and auto-resume. The idle timeout (commonly 60 seconds by default, tunable down to a Snowflake-enforced floor) that returns credits when the warehouse goes quiet, and the auto-resume flag that spins it back up on demand. Aggressive auto-suspend saves money but can cold-start dashboards; lax settings quietly bleed credits.

What does a right-sized configuration actually look like?

A right-sized warehouse holds three attributes in balance:

Attribute	Typical range	Why it matters
Size	XS – 4XL	Governs per-query latency and memory (spill avoidance)
Clusters (min/max)	1 / 1 – 1 / 10	Governs concurrency and queue depth under load
Auto-suspend	30 – 600 seconds	Governs idle-cost leakage vs. cold-start penalty

The clarification matters because engineers often "right-size" by shrinking the T-shirt size, watch p95 latency spike, and roll it back — when the real fix was raising max clusters and tightening auto-suspend. True right-sizing optimizes all three axes against a query SLA, not one axis against a monthly bill.

Why do oversized warehouses silently inflate Snowflake costs?

Oversized warehouses silently inflate Snowflake spend because credits are billed per second of warehouse uptime at a size-dependent rate, regardless of whether the compute is actually saturated. Per Snowflake's published warehouse credit-consumption table, a Small warehouse burns roughly 2 credits per hour, a Medium about 4, and a Large about 8, with each step up the T-shirt ladder doubling the meter — so a Large running a query that would have finished on a Small at the same wall-clock time costs roughly 4x as much for zero SLA benefit. That waste accumulates quietly across hundreds of virtual warehouses and thousands of daily jobs, which is why the bill grows faster than the workload.

Where does the silent waste actually hide?

Three specification-level patterns account for most of it:

Idle auto-suspend tails. Warehouses stay warm for the configured suspend window (often 60–600 seconds) after the last query, billing full-size credits for an empty cluster.
Concurrency headroom that never materializes. Teams size up "just in case" a peak arrives; if the peak never lands on that warehouse, the extra size is pure overhead.
Mismatched query profiles. Small, metadata-heavy queries (dbt tests, BI cache refreshes, agent calls) routed to XL warehouses consume credits at XL rates while using a fraction of the compute.

What should you do, and what should you watch out for?

Do this	But watch out for
Downsize warehouses toward observed p95 concurrency	Aggressive downsizing can breach query SLAs on genuine peaks
Shorten auto-suspend to 60 seconds	Frequent cold starts add latency to interactive BI
Route light workloads to a dedicated small warehouse	Manual routing rules drift as dbt models and dashboards evolve
Cap agent and ad-hoc traffic	Hard caps can starve legitimate exploratory analysis

Highest-impact mitigation: treat right-sizing as a continuous control loop, not a quarterly cleanup. The workloads shift weekly — dbt models get added, BI dashboards get rebuilt, AI-agent traffic spikes — so any static configuration decays into either overspend or SLA misses within a release cycle.

How do you measure whether a warehouse is oversized or undersized?

To measure whether a Snowflake warehouse is correctly sized, you need to interpret four telemetry streams together rather than in isolation: query queue time, execution time, local and remote spillage, and average warehouse load. Any single metric can mislead — a low load number can hide short bursts that break SLAs, and a fast execution time can mask expensive spillage to disk.

You may also be wondering which thresholds actually matter, how to read them from Snowflake's ACCOUNT_USAGE and QUERY_HISTORY views, and when a metric is a symptom versus a root cause. The attribute list below defines each signal, its useful range, and why it drives sizing decisions.

Which telemetry attributes should you track?

Queue time (QUEUED_OVERLOAD_TIME) — Allowed values: milliseconds per query. Consistently above a few seconds during business hours indicates undersized compute or insufficient clusters in a multi-cluster warehouse. Directly threatens interactive SLAs.
Execution time (EXECUTION_TIME) — Allowed values: milliseconds. Compare distributions (p50, p95, p99), not averages. A rising p95 while p50 stays flat usually signals contention, not a bigger workload.
Local spillage (BYTES_SPILLED_TO_LOCAL_STORAGE) — Non-zero values mean the warehouse ran out of memory and used SSD. Tolerable in small doses; chronic local spill on the same query pattern points to an undersized T-shirt size.
Remote spillage (BYTES_SPILLED_TO_REMOTE_STORAGE) — Almost always a red flag. Remote spill inflates execution time and credit burn simultaneously; it's the strongest single argument for scaling up.
Average warehouse load (AVG_RUNNING in WAREHOUSE_LOAD_HISTORY) — Allowed values: 0 to N. As a rough rule of thumb we use, consistently low average load across the day with no queueing is a strong oversizing signal, while consistently high sustained load accompanied by queueing points to undersizing.
Idle time and auto-suspend gaps — Long idle windows between bursts inflate credit consumption on oversized warehouses that never fully drain.

What does the combined pattern tell you?

Read the signals as a matrix. Low load plus zero queue plus zero spill means you are paying for headroom you don't use. High queue plus healthy execution means add concurrency, not size. Spillage plus long execution means scale up the T-shirt. Fluctuating load with intermittent queueing is the hardest case — it's typically why teams over-provision defensively, and it's where automated, query-level routing pays off most.

Which query SLA signals matter most when resizing warehouses?

The query SLA signals that matter most when resizing Snowflake warehouses fall into four measurable categories, and downsizing decisions must be constrained by all of them simultaneously. Before touching a warehouse size, define which signals you will hold constant, which you will trade, and how you will weight them — otherwise a "cost win" quietly becomes a latency regression that surfaces in a Monday dashboard review.

Which criteria should you evaluate before resizing?

Weight these four criteria in the order below, because each one gates the next:

Tail latency (p95/p99): The 95th and 99th percentile query duration for user-facing dashboards and reverse-ETL jobs. Averages hide the queries that break trust; percentiles do not. Weight this highest for interactive workloads.
Throughput under concurrency: Queries-per-minute the warehouse sustains at your peak concurrent user count without queuing. A smaller warehouse can match average latency yet collapse when concurrency spikes — watch QUEUED_OVERLOAD_TIME in QUERY_HISTORY.
Concurrency ceiling: The maximum simultaneous queries before Snowflake queues or spills. This is a hard constraint, not a knob — downsizing without multi-cluster scaling policy changes will hit it first.
Freshness / job completion windows: Batch and dbt model SLAs (e.g., "gold layer ready by 06:00 UTC"). A downsized warehouse that meets p95 but blows the ELT window is still a failure.

How should these signals be compared?

Signal	What it constrains	Weight for interactive BI	Weight for batch/dbt
p95/p99 latency	User experience	High	Medium
Throughput at peak concurrency	Scalability headroom	High	Medium
Concurrency ceiling	Queue formation	High	Low
Job completion window	Pipeline freshness	Low	High

Right-sizing without a percentile-anchored baseline is guesswork — and it is why so many manual downsizing attempts in 2026 quietly revert within a sprint.

How should you compare vertical scaling versus multi-cluster scaling?

To compare vertical scaling against multi-cluster scaling, weigh how each approach reshapes cost, concurrency, and query SLAs before you touch a single warehouse setting. Vertical scaling (resizing a warehouse from, say, Medium to Large or X-Large) doubles compute per step and accelerates individual heavy queries. Multi-cluster scaling adds parallel clusters of the same size to absorb concurrent query load without changing per-query speed.

Which criteria should drive the decision?

Before comparing, fix the evaluation criteria in this order of weight:

Query shape: Are your bottlenecks long-running scans and joins, or many short queries queuing behind each other?
Concurrency profile: Is load spiky (BI dashboards at 9am, dbt runs at midnight) or steady?
SLA sensitivity: Which queries have hard latency commitments to stakeholders or customers?
Credit economics: Vertical steps double credits-per-second; multi-cluster steps add linear credit draw only while extra clusters are active.
Blast radius: A wrong vertical resize affects every query; a wrong min-cluster setting affects only queue behavior.

How do the two approaches compare in practice?

Criterion	Vertical scaling (bigger warehouse)	Multi-cluster scaling (more clusters)
Best for	Heavy single queries, large scans, complex joins	High concurrency, many short-to-medium queries
Effect on per-query latency	Faster (more memory, more threads)	Unchanged
Effect on queuing	Minimal	Eliminates queue backlog
Credit cost pattern	Doubles per size step, always-on while running	Adds a full cluster's credits only when spun up
SLA risk if wrong	Over-spend on idle capacity; under-size stalls all users	Under-min stalls peaks; over-max hides inefficient queries
Reversibility	Instant resize	Instant cluster count change

Verdict: use vertical scaling to meet latency SLAs on individually expensive queries, and multi-cluster scaling to meet concurrency SLAs during predictable peaks — most mature Snowflake estates need both, tuned per workload rather than per warehouse.

Why do most teams over-provision both dimensions?

The result is quadratic credit burn. Yuki Data addresses this by routing and shaping traffic in real time — every query lands on the right compute footprint without engineers pre-guessing peak shape.

Frequently Asked Questions

What is warehouse right-sizing in Snowflake?

Warehouse right-sizing is the practice of matching Snowflake virtual warehouse size (X-Small through 6X-Large) and cluster count to actual workload demand, so you pay for the compute you need without starving concurrent queries. Done well, it holds query SLAs steady while eliminating idle credits burned on oversized clusters.

How do I right-size a Snowflake warehouse without breaking query SLAs?

Baseline each warehouse's peak concurrency, queue depth, and p95 runtime for a representative window (typically two to four weeks), then step down one size at a time while watching for spillage to remote disk and queue growth. Pair the size reduction with multi-cluster auto-scale so bursts still land within SLA rather than piling up in the queue.

Why does over-provisioning still happen despite Snowflake's elasticity?

Snowflake makes it easy to scale up but places the sizing decision — and the blame for slow dashboards — on the data team. Faced with a peak-hour incident, most teams bump the warehouse up a size and never bump it back down, so provisioning ratchets upward over quarters. The elasticity is real; the feedback loop that would exercise it is missing.

Can right-sizing be automated safely?

Yes, when the automation layer sees per-query cost, concurrency, and SLA context before routing decisions are made. Yuki Data automates warehouse selection and load balancing at the connection layer, so queries land on appropriately sized compute without code changes; Alex Ahlstrom (Snowflake Lead) reports around a 60% cost reduction alongside load balancing using this approach, according to Yuki Data.

How does right-sizing interact with dbt workloads?

dbt model runs have predictable shapes — long-running transformations, short incremental models, ad-hoc tests — that benefit from different warehouse sizes. Model-level cost and performance reporting lets you assign each model to the right warehouse tier rather than defaulting everything to a single oversized cluster. Wild Alaskan achieved a 48% Snowflake cost reduction on its dbt stack, according to Yuki Data.

What is the fastest way to see whether we are over-provisioned?

Pull WAREHOUSE_METERING_HISTORY and QUERY_HISTORY for the last 30 days and calculate average concurrency versus configured cluster count, plus the ratio of queued time to execution time. If queues are near zero and average concurrency sits well below cluster capacity, you are paying for headroom you never use. Tenable identified and captured a 33% reduction within two weeks using an automated layer, according to Yuki Data.

About this article

Yuki Data publishes this article under its own name and is responsible for its accuracy. Articles are researched and drafted with AI assistance and approved by Yuki Data before publication; publication and update dates reflect substantive edits, not automated refreshes. Last updated: 2026-07-04