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 affect another’s performance.

Product details below were checked against Snowflake’s documentation in September 2026.

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 slowing interactive users. 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.

References: Snowflake Documentation, Overview of warehouses; Snowflake Documentation, Warehouse considerations.