Get a starting-point warehouse size (XS to 6XL) based on workload type, data volume, and concurrency. Use it as a first cut, then right-size using real query profiles on production data.
How should I choose a Snowflake warehouse size?
Start small (XS or S) and monitor query runtimes. If queries routinely exceed your latency SLA or spill to remote disk, bump up one size. Bigger warehouses finish faster and often cost the same - a 2XL running 30 seconds may equal a Small running 8 minutes. Size to your critical-path query, not to your smallest queries.
Warehouse sizes and credit consumption
X-Small (XS): 1 credit/hour - dev, sandbox, small dashboards
Small (S): 2 credits/hour - small ETL, simple BI
Medium (M): 4 credits/hour - typical production BI and ETL
Large (L): 8 credits/hour - heavier ETL, feature engineering
X-Large (XL): 16 credits/hour - large batch jobs, ML prep
2XL-6XL: 32-512 credits/hour - massive data volumes (only when needed)
When do I need multi-cluster warehouses?
Multi-cluster solves concurrency, not data volume. If 30+ BI users fire queries simultaneously and some queue for 10+ seconds, enable multi-cluster with auto-scale. Snowflake will spin up additional clusters only when concurrent demand exceeds one cluster's capacity, then scale back down.
Workload-based sizing heuristics
BI / Dashboards: Latency-sensitive. Prefer one size larger with multi-cluster for concurrency.
Ad-hoc / exploration: Moderate data, relaxed latency. M or L works well.
ETL / batch: Throughput-sensitive. Size to the largest table scanned per query.
ML feature prep: Often massive joins. L to 2XL is typical; check for remote disk spillage.
Dev / sandbox: Always XS. Use resource monitors to cap spend.
How to validate your size
Run your top 10 queries on the recommended warehouse
In each Query Profile, check for "Bytes spilled to remote storage" - any remote spill means the size is too small
Check WAREHOUSE_LOAD_HISTORY - if average load is consistently >1.0, add multi-cluster
Check QUEUED_LOAD_PERCENTAGE - sustained queueing >10s means concurrency is saturating
Review WAREHOUSE_METERING_HISTORY after a week and right-size down if utilization is low