Virtual Warehouse

A virtual warehouse is Snowflake’s unit of compute: a cluster of compute resources that runs queries, loads data, and performs other DML. Storage is separate, so several warehouses can read the same tables at the same time, and Snowflake’s documentation states that warehouses do not share compute resources with each other — one warehouse’s load does not take another’s compute. Warehouses can still wait on each other in other ways: through locks when they write the same tables, and through shared data dependencies.

Size and what it costs

A warehouse has a size, and each step up doubles the compute and the credit rate. For Gen1 standard warehouses the documented rates start at 1 credit per hour for X-Small, then 2 for Small, 4 for Medium, 8 for Large, and so on up the ladder. Billing is per second, with a 60-second minimum each time a warehouse starts, and by default a warehouse suspends itself after a period of inactivity and resumes automatically when a statement needs it.

Two consequences follow. First, a larger warehouse is not automatically more expensive for a given job: if doubling the size roughly halves the run time, the credits are similar. That is a condition, not a guarantee — the documentation notes that larger is not necessarily faster for small, basic queries, so for those a bigger size simply costs more. Snowflake suggests testing the same queries on several sizes to find out. Second, the 60-second minimum makes frequent restarts expensive. The documentation recommends a low auto-suspend value but cautions that if queries arrive every few minutes, suspending and resuming between them is counterproductive.

Resizing a running warehouse does not speed up queries already running; the added resources become available to queued and newly submitted queries once provisioned.

Size is not the concurrency lever

When a warehouse lacks the resources to run everything submitted, additional queries wait in a queue. It is tempting to answer a queue with a bigger size, and it can help, because each query finishes sooner and the queue drains faster. But Snowflake’s guidance draws the line explicitly: resizing is not intended for handling concurrency issues. For many simultaneous users and queries, the documented answer is more warehouses or a multi-cluster warehouse.

A practical way to tell the problems apart is to ask whether a slow query is slow while running or slow while waiting. Running time responds to size. Waiting time responds to more clusters or more warehouses.

Warehouses as a design unit

Because warehouses are independent, they are the natural way to separate workloads. A warehouse for loading, one for transformation, one for dashboards, and one for ad hoc analysis gives each its own size, its own suspension setting, and its own line in the bill, and keeps a heavy load from taking the compute interactive users need. The cost is more things that can be left running — which is what auto-suspend and resource monitors are for.

Warehouse usage is measured in Snowflake credits. How warehouses fit alongside storage and the cloud services layer, and how each is billed, is worked through in Snowflake Architecture: Three Layers and What Each One Bills For.

Further reading

• Snowflake Documentation, Overview of warehouses
• Snowflake Documentation, Warehouse considerations
• Snowflake Documentation, Transactions