Snowflake Cost Control: A Practical Guide to Managing Credits

Snowflake's credit-based pricing is transparent — you can see exactly what you are paying for and why. This transparency is also what makes cost control tractable: the levers are visible and the impact of changes is measurable. This guide covers the specific settings and practices that control Snowflake costs at every layer.

Understanding Credit Consumption

Snowflake costs come from three sources:

**Virtual warehouse compute:** Credits consumed when warehouse processes are running — actively executing queries or sitting idle (waiting for queries). This is the primary cost driver for most organisations.

**Snowflake-managed services:** Credits consumed by automated operations including automatic clustering maintenance, materialised view refresh, Snowpipe loading, and search optimisation service. These are less visible but accumulate meaningfully at scale.

**Storage:** Charged per TB per day for data in Snowflake-managed storage (tables, stages). Active storage and long-term storage are charged at different rates; tables not modified for 91+ days qualify for the lower long-term rate automatically.

The credit consumption breakdown from ACCOUNT_USAGE.METERING_HISTORY identifies which category is driving costs:

select

service_type,

sum(credits_used) as total_credits,

sum(credits_used) * <credit_price> as estimated_cost

from snowflake.account_usage.metering_history

where start_time >= dateadd('month', -1, current_timestamp())

group by service_type

order by total_credits desc;

Virtual Warehouse Cost Control

### Auto-Suspend Configuration

Every virtual warehouse should have auto-suspend enabled. A warehouse that has been idle for more than the auto-suspend threshold suspends automatically, stopping credit consumption. A suspended warehouse resumes automatically when a query arrives.

The default auto-suspend on new warehouses is 600 seconds (10 minutes). This is too long for most analytical workloads. Configure auto-suspend to 60–300 seconds (1–5 minutes) depending on the workload pattern:

- **Interactive analyst query warehouses:** 60–120 seconds. Analysts work in bursts; a warehouse idle for 2 minutes between queries should suspend.

- **dbt production run warehouse:** 120–300 seconds. Production runs are sequential; brief idle periods between model executions should not trigger suspension.

- **Reporting/BI tool warehouse:** 60 seconds. BI tool queries are predictably bursty; fast auto-suspend is appropriate.

**Auto-resume is instantaneous for most warehouse sizes** — a suspended warehouse handling a query from a BI tool adds 1–3 seconds of resume latency, which is typically acceptable.

### Warehouse Sizing

Larger warehouses do not always mean faster queries. Snowflake warehouse size (X-Small, Small, Medium, Large, X-Large, etc.) doubles compute resources and credit consumption at each size tier. A query that is limited by data scanning rather than computation will not run faster on a larger warehouse.

The scenarios where a larger warehouse helps:

- Complex multi-join queries processing large data volumes

- dbt model runs with many parallel tasks

- High-concurrency environments where many simultaneous queries are queuing

The scenarios where a larger warehouse does not help:

- Simple queries that scan large tables with partition pruning (scan is the bottleneck, not compute)

- Low-concurrency environments with few simultaneous queries

- Queries that are already fast on a smaller warehouse

Test warehouse sizing empirically: run a representative sample of your slowest queries at X-Small, Small, and Medium sizes. Measure both execution time and credit consumption (larger warehouses burn more credits per second). The right size is the one where additional credits buy meaningful time reduction.

### Multi-Cluster Warehouses

Multi-cluster warehouses automatically add cluster instances when concurrent query load exceeds single-cluster capacity, and remove instances when load decreases. They are designed for high-concurrency workloads where many users query simultaneously.

Multi-cluster warehouses are only available on Enterprise edition and above. Each additional cluster consumes credits at the same rate as the primary cluster — a 3-cluster warehouse running at full capacity consumes 3x the credits of a single-cluster warehouse.

**When to use:** BI tool warehouses serving many concurrent dashboard users; reporting environments with scheduled batch queries that run simultaneously.

**When not to use:** Development warehouses with one or two simultaneous users; dbt pipeline warehouses where jobs run sequentially; low-concurrency analytical environments.

### Dedicated Warehouses by Workload

Mixing workloads on the same warehouse creates contention and makes cost attribution difficult. Use separate warehouses for different workload types:

- One warehouse for dbt production runs

- One warehouse for interactive analyst queries

- One warehouse for BI tool / dashboard queries

- One warehouse for data loading (if not using Snowpipe)

Separate warehouses allow independent sizing and auto-suspend configuration for each workload type, and provide clear cost attribution by warehouse.

Resource Monitors

Resource monitors are Snowflake's built-in cost governance tool. A resource monitor defines a credit budget for a warehouse or account, with actions at defined consumption thresholds.

Example: a resource monitor on the analytics team's warehouse that:

- Sends a notification at 75% of the monthly credit budget

- Sends a notification at 100% of budget

- Suspends the warehouse at 110% (preventing further consumption)

Create resource monitors in the Snowflake console under Admin > Resource Monitors, or via SQL:

CREATE RESOURCE MONITOR analytics_team_monitor

WITH CREDIT_QUOTA = 1000 -- monthly credit budget

TRIGGERS

ON 75 PERCENT DO NOTIFY

ON 100 PERCENT DO NOTIFY

ON 110 PERCENT DO SUSPEND;

ALTER WAREHOUSE analytics_wh

SET RESOURCE_MONITOR = analytics_team_monitor;

Resource monitors reset at the start of each credit quota period (monthly by default). They are the right tool for setting credit budgets per team or per use case and alerting before the budget is exceeded.

Query Performance and Cost

Individual expensive queries are often the primary driver of unexpected cost spikes. Identifying and optimising them is both a performance and cost activity.

The most expensive queries by credit consumption:

select

query_id,

query_text,

execution_time / 1000 as exec_time_seconds,

credits_used_cloud_services,

total_elapsed_time / 1000 as total_time_seconds

from snowflake.account_usage.query_history

where start_time >= dateadd('day', -7, current_timestamp())

and credits_used_cloud_services > 0

order by credits_used_cloud_services desc

limit 20;

For each expensive query, open the Query Profile in the Snowflake UI to identify the bottleneck: table scan (micro-partition filtering not working — review clustering), remote disk I/O (data spilling to disk — increase warehouse size or reduce query scope), or shuffle (join order or distribution problem).

### Clustering Keys for Cost Reduction

Well-chosen clustering keys allow Snowflake to skip micro-partitions during table scans, reducing the bytes scanned and credits consumed per query. A table clustered on order_date where queries always filter by date range will scan far fewer micro-partitions than an unclustered table.

Automatic Clustering maintains the clustering automatically as new data is loaded. Check the clustering state of large tables:

select system$clustering_information('my_database.my_schema.fact_orders', '(order_date)');

Tables with poor clustering depth (many micro-partitions that overlap on the clustering key) benefit most from enabling Automatic Clustering.

**Automatic Clustering credit cost:** Automatic Clustering consumes serverless credits to maintain clustering. For tables with high write volumes (many INSERTs or frequent bulk loads), the clustering maintenance cost can be significant. Monitor AUTOMATIC_CLUSTERING_HISTORY to track maintenance credit consumption.

Search Optimisation Service

The Search Optimisation Service (SOS) is a Snowflake feature that builds access path structures to accelerate point lookup queries — queries that filter on individual, specific values rather than ranges. It is useful for use cases like "look up this specific customer ID" rather than "scan all orders from January."

SOS consumes serverless credits continuously to maintain its access structures. Do not enable it unless you have confirmed that point lookup performance is a real bottleneck in your workload — the ongoing credit consumption can be significant.

Storage Cost Management

**Short-term retention:** Snowflake's Time Travel feature retains previous versions of data for a configurable period (1 day default; up to 90 days on Enterprise). Time Travel storage is charged at the same rate as active storage. Setting retention to 1 day (the minimum) for tables that do not need extensive point-in-time recovery reduces storage cost.

**Fail-safe storage:** Snowflake automatically maintains a 7-day fail-safe backup of all data beyond the Time Travel period. Fail-safe storage is non-configurable and charged at a lower rate than active storage. It cannot be disabled.

**Zero-copy cloning:** Cloning tables in Snowflake does not consume storage until the clone diverges from the source. Development and test environments that clone production data cost nothing extra at creation time. As the clone is modified (new data loaded, rows deleted), only the delta consumes storage.

Our data architecture consulting practice designs and optimises Snowflake architectures including cost management — contact us to discuss Snowflake cost control for your environment.

A former Microsoft data architect audits your data foundation, identifies your top priorities, and sends you a written plan. Free. No pitch.