Snowflake Warehouse: Sizes, Credits and Suspend Behaviour

A Snowflake virtual warehouse is the compute that Snowflake requires for queries and for all DML operations, including loading data into tables. It is separate from storage: a warehouse can be started, suspended, or resized at any time without touching the data in your databases. Because warehouses bill credits only while running, understanding size, billing granularity, and suspend behaviour is most of understanding Snowflake compute cost.

Size sets the credit rate

Each size doubles the compute per cluster, and the credit rate doubles with it. For Gen1 standard warehouses, Snowflake’s documented rates are:

X-Small is the default for warehouses created with CREATE WAREHOUSE. Check the size of warehouses people created by hand in the UI rather than assuming the default, because each step up doubles the hourly rate. A multi-cluster warehouse, an Enterprise Edition feature, is billed on size multiplied by the number of clusters that ran: a 3X-Large warehouse running one cluster for an hour and two the next bills 64 + 128 = 192 credits.

Per-second billing with a 60-second minimum

Warehouses bill per second, with a 60-second minimum each time the warehouse starts or resumes. A warehouse that runs 61 seconds, shuts down, then restarts and runs under 60 seconds is billed 121 seconds. That minimum is why very short auto-suspend settings can backfire on bursty workloads: Snowflake’s own example: with regular gaps of 2 or 3 minutes between queries, a 1 or 2 minute auto-suspend leaves the warehouse continually suspending and resuming, billed the 60-second minimum on every resume.

Auto-suspend and auto-resume

Both are enabled by default. Auto-suspend stops a warehouse after a period of inactivity; auto-resume starts it when a statement needs it. Snowflake recommends a low auto-suspend value, such as 5 or 10 minutes or less, adjusted to workload. Two details matter:

• Auto-suspend applies to the whole warehouse, not to individual clusters; on a multi-cluster warehouse it only happens when the minimum number of clusters is running and idle.
• Each running warehouse keeps a cache of table data. The cache is dropped on suspend, so the first queries after resume can be slower until it rebuilds.

Suspending is safe for data: it stops compute only. A warehouse suspended while statements are running lets them complete before its resources shut down.

Suspend on a schedule, or on idle?

Auto-suspend reacts to inactivity, and auto-resume will wake a warehouse for any stray query, including a dashboard refresh at 3 AM. A schedule is a different control: it keeps a warehouse suspended through a known off-hours window. For warehouses that serve business-hours users only, the two work together: a short auto-suspend during the day, and a scheduled suspend at night.

Warehouses in ZopNight

ZopNight connects Snowflake as its own account using key-pair JWT or a personal access token, discovers warehouses and other objects from SNOWFLAKE.ACCOUNT_USAGE and SHOW queries, and can suspend and resume warehouses on the same schedules, groups, and overrides used for cloud resources. Its Snowflake recommendations include a warehouse whose AUTO_SUSPEND is unset, zero, or above 120 seconds, and idle, oversized, and under-utilized warehouses. See scheduling Snowflake warehouses and Snowflake cost optimization.