AdvancedLast updated: 2026-04-27 • 4 sections
Expert questions on credit consumption, warehouse sizing, auto-suspend, resource monitors, serverless costs, and strategies to reduce spend 30–60%.
Q: What consumes Snowflake credits and what is completely free?
Credits: warehouse compute (per second, XS=1 to 6XL=512 cr/hr), cloud services above 10% of daily WH compute, serverless (Snowpipe, auto-clustering, MV refresh, Search Optimization, DT refresh, Streaming), Cortex AI (per-token). Storage: $/TB/month for data + Time Travel + Fail-Safe. Free: metadata-only queries, suspended warehouse idle time, result cache hits, data sharing (consumer pays their own compute).
Q: Walk through a $50K/month Snowflake cost reduction audit.
Framework: (1) WAREHOUSE_METERING_HISTORY — top 5 warehouses, oversized? auto-suspend configured? (2) QUERY_HISTORY top-50 most expensive queries — full table scans, missing clustering? (3) Serverless histories — clustering on rarely-changed tables? excessive MV refreshes? (4) Storage — high Time Travel retention on large tables? Fail-Safe on tables that could be transient? (5) Cloud services over 10% threshold? Typical savings mix: 20% sizing, 15% auto-suspend, 10–20% query tuning, 5–10% storage.
Q: What are optimal auto-suspend settings for different workload types?
ETL pipelines: 60s — clear start/end, minimal idle cost. BI/dashboard warehouses: 300s — keep cache warm between dashboard refreshes. Ad-hoc exploration: 300–600s — analysts expect fast first queries. Data science: 900–1800s — long compute sessions, startup cost is significant. Never set 0 (means never suspend, wastes credits indefinitely). Always enable auto-resume. For sporadic workloads, prefer START_WAREHOUSE per job instead of idle warehouses.
Q: How do multi-cluster warehouses affect cost vs concurrency?
Auto-scale 1–N clusters handle concurrency spikes. STANDARD policy adds a cluster after 20s queue; ECONOMY waits 6 minutes (cheaper, more latency). Cost can be lower than always-on larger warehouse: MEDIUM dynamic (1–3 clusters, 4–12 cr/hr) vs always-on XL (16 cr/hr). Can cost more: aggressive scaling for brief bursts incurs 60s minimum billing per cluster. Best practice: MIN=1, MAX=2–3, policy=ECONOMY for most workloads.
Q: How do resource monitors work and what triggers do you configure?
Resource monitors track credit usage per warehouse or account. Triggers: NOTIFY (send alert email at X% of quota), SUSPEND (stop new queries at Y%, ongoing queries finish), SUSPEND_IMMEDIATE (kill all queries at Z%). Configure at the account level for overall governance and at the warehouse level for per-team budgets. Best practice: set NOTIFY at 75%, SUSPEND at 100%, SUSPEND_IMMEDIATE at 120%. Reset frequency: daily, weekly, or monthly.
Q: How do you identify and fix the most expensive queries in an account?
Query WAREHOUSE_METERING_HISTORY and QUERY_HISTORY: ORDER BY CREDITS_USED DESC. Look for: partitions_scanned >> partitions_total (poor pruning → add clustering), bytes_spilled_to_local_storage > 0 (memory pressure → scale up warehouse), compilation_time > execution_time (complex planning → simplify query). Fix in order: clustering, warehouse sizing, query rewrite. Test changes on LIMIT 100 before production runs.
Q: How do you reduce storage costs in Snowflake?
Reduce Time Travel retention: default 90 days on Enterprise is expensive. Use DATA_RETENTION_TIME_IN_DAYS=1 for staging tables, 7 days for most production tables, 30–90 only for critical audit tables. Use Transient tables for intermediate ETL data (no Fail-Safe, 0–1 day Time Travel). Delete or archive infrequently accessed data. Monitor STORAGE_USAGE table for per-database growth trends. Large tables with high update rates accumulate significant Time Travel storage.
Q: When does auto-clustering cost more than it saves?
Auto-clustering runs continuously in the background, billing serverless credits. It costs more than it saves when: the table is small (< 100GB), the query mix is too varied for a single clustering key to help, the table has very high write churn (clustering re-runs constantly), or queries are already running in < 1s without clustering. Check AUTOMATIC_CLUSTERING_HISTORY for credits spent vs QUERY_HISTORY for query improvement. If pruning did not improve, disable auto-clustering.
For most accounts, proper auto-suspend configuration on idle warehouses is the single highest-impact change because it requires no code changes and immediately stops credit bleed. The second highest impact is usually query clustering — a few expensive queries with 100% partition scan rates can burn more credits than the rest of the account combined. Start with WAREHOUSE_METERING_HISTORY to identify idle warehouses, then QUERY_HISTORY to find the top-credit-consuming queries.
Step 1: run the query once with EXPLAIN to get partition count and estimated bytes scanned. Step 2: run on LIMIT 1000 with a timer. Step 3: extrapolate and estimate warehouse size needed. Step 4: check the Snowflake credit consumption table for your warehouse size and region. Step 5: factor in result cache benefits (repeated queries are free). For batch ETL: time the job on a small warehouse and compare cost vs duration on a larger warehouse (sometimes XL is cheaper than 2× M due to fewer wall-clock seconds).
Resource monitors: account or warehouse-level credit quotas with configurable suspend/notify triggers. Native Snowflake feature, granular control, can hard-stop warehouses. Budgets: a newer feature that tracks spend across any Snowflake object type (including serverless) and sends notifications — but cannot suspend warehouses. Use resource monitors for hard enforcement on warehouse compute. Use budgets for broad spend visibility across all object types including serverless features.