Virtual Warehouses: Sizing, Auto-Suspend & Auto-Resume

Configure compute clusters efficiently to balance performance and cost.

A virtual warehouse is a cluster of machines that runs your queries. It is the only thing in Snowflake that consumes compute credits, so it is where your bill comes from.

A virtual warehouse is like renting a moving truck by the hour — you pick the truck size for the job, and it automatically returns itself (stops billing) the moment you're done unloading.

Key Concepts

Sizes double, and so does the cost.

    X-Small    1 credit / hour
    Small      2
    Medium     4
    Large      8
    X-Large   16 ... up to 6X-Large

Each step doubles the machines and doubles the rate.

Which means doubling is often free. If a query scales well, a Medium finishes it in half the time a Small takes, at twice the rate — the same credits, in half the wall-clock time:

    Small:   4 credits/hr x 0.5 hr = 2 credits
    Medium:  8 credits/hr x 0.25hr = 2 credits

So for a large query, a bigger warehouse is frequently the same cost and much faster. This surprises people who assume bigger always means more expensive.

It stops holding when the query is too small to use the extra machines. A query touching three files cannot be spread over sixteen nodes, so on a small query the larger warehouse costs twice as much for the same duration.

The real sizing signal is spilling. When a warehouse runs out of memory it writes intermediate results to local disk, then to remote storage. The query profile reports both.

    spilling to local storage   -> slower, tolerable
    spilling to remote storage  -> much slower, size up

No spilling and a short runtime means you could probably size down.

Auto-suspend is the setting that controls your bill. A warehouse charges by the second while running, whether or not anyone is querying:

    auto-suspend 60s   -> idle costs stop a minute after the last query
    auto-suspend never -> a forgotten warehouse bills 24 hours a day

Set it low — 60 seconds is common. Auto-resume brings it back in a second or two when the next query arrives, so users rarely notice.

The counter-argument is the local disk cache: suspending clears it, so the next query re-reads from object storage. For a dashboard queried every few minutes, a slightly longer suspend keeps the cache warm. That is a real trade, but it is measured in seconds of latency against hours of billing.

Resizing takes effect without downtime. Running queries finish on the old size; new queries get the new one. So it is normal to scale up for an overnight load and back down for the day, either on a schedule or in the job itself.

Size and multi-cluster solve different problems. A bigger warehouse makes a single query faster. A multi-cluster warehouse adds clusters when many users queue at once. Slow query means size up; queuing means more clusters.

What the interviewer is probing.1. "How do you decide a warehouse size?" Probing: the method. Stalls: "Start large." *Moves up:* by measurement — each size doubles cost and roughly halves runtime for scannable work, so if it does not halve, the query is not the bottleneck.

2. "Why can a bigger warehouse cost the same?" Probing: the insight. Stalls: "It cannot." Moves up: billing is per second of runtime times size, so if doubling size halves the time, the cost is identical and the answer arrives sooner.

3. "What auto-suspend value do you pick?" Probing: the trade. Stalls: "The default." *Moves up:* short for ad-hoc work to stop idle burn, longer where the warehouse cache matters, because suspending drops it.

4. "What is the billing minimum?" Probing: the gotcha. Stalls: "Per second." Moves up: a 60-second minimum per resume, so very aggressive auto-suspend on a trickle of queries can cost more than a longer timeout.