Snowflake cost optimization means paying only for the compute, storage and services your work actually needs. Most of the savings come from four places: warehouses that run idle or oversized, queries that scan more data than they need, background features nobody uses any more, and spend that nobody owns. This guide explains where Snowflake money goes, the most common causes of waste, 17 techniques to cut costs without slowing your pipelines, and how to keep costs down once they are under control.
It is written for the people who own the Snowflake bill: data platform leads, heads of data and the finance partners who ask them about it. Engineers will find the SQL for every step. Every fact and figure in this guide was checked against Snowflake’s documentation.
In this guide: what Snowflake cost optimization is · where your money goes · the most common causes of wasted spend · 17 ways to cut costs · cutting costs without slowing pipelines · keeping costs down · doing it by hand or automating it · FAQ
What is Snowflake cost optimization?
Snowflake cost optimization is the work of lowering your Snowflake bill without losing the performance or data your teams depend on. Because Snowflake charges for what you use, every idle warehouse minute, unnecessary table scan and forgotten background feature shows up on the bill. Optimization finds those, removes them, and keeps them from coming back.
It is not a one-off cleanup. Workloads, defaults and prices change: new warehouses are now Gen2 by default, Query Acceleration is switched on for new Gen2 warehouses on Enterprise, and clustering billing changed on 1 September 2026. Costs that were right-sized last quarter drift.
Where does your Snowflake money go?
A Snowflake bill has six parts. Compute is usually the largest, and most savings come from it.
| Part of the bill | What you pay for | How it is billed |
|---|---|---|
| Warehouse compute | Virtual warehouses running queries | Credits per hour by size, per second, 60-second minimum |
| Serverless features | Snowpipe, clustering, materialized views, tasks and others | Credits per compute-hour at each feature’s rate, or per GB |
| Cloud services | Metadata, query compilation, logins | Credits, only above 10% of daily warehouse use |
| Storage | Tables, stages, Time Travel and Fail-safe | Per compressed TB per month |
| Data transfer | Data leaving your region or cloud | Per TB |
| AI services | Cortex AI functions, agents and Cortex Code | AI Credits |
A credit costs $2.00 on Standard, $3.00 on Enterprise and $4.00 on Business Critical, on demand in AWS US East. Our Snowflake pricing guide explains every line, with example bills.
To see how your own bill splits, run this against your account:
-- Credits billed by service type, last 30 days
SELECT service_type,
SUM(credits_billed) AS credits_billed
FROM snowflake.account_usage.metering_daily_history
WHERE usage_date >= DATEADD(day, -30, CURRENT_DATE())
GROUP BY 1
ORDER BY 2 DESC;
WAREHOUSE_METERING is your warehouses. Everything else is serverless features, AI and other services.
What are the most common causes of wasted Snowflake spend?
Most wasted Snowflake spend comes from defaults and habits, not from Snowflake’s prices. These are the causes we see most often, roughly in the order they cost money:
- Idle warehouse time. A warehouse bills every second it runs, busy or not, and new warehouses wait 600 seconds before suspending. See smart auto-suspend.
- Oversized warehouses. A query that runs fine on Medium costs four times as much per second on X-Large. Sizes chosen for a peak often never come back down. See warehouses that never got resized back.
- Frequent short resumes. Every start or resume is billed for at least 60 seconds, so a warehouse woken every few minutes for a tiny query pays for minutes it never uses.
- Extra clusters that linger. Multi-cluster warehouses add clusters quickly under load and can keep them running after the load has gone.
- Queries that scan too much. SELECT * on wide tables, filters applied late and missing pruning make every run cost more than it should.
- Background features nobody uses. Clustering, materialized views and search optimization keep billing on tables that nobody queries any more.
- Storage history on busy tables. Long Time Travel on tables that are rewritten often stores many copies of data.
- Pipelines and tables nobody needs. Old tasks, scheduled jobs and tables keep running or keep being stored long after their consumers are gone. See the hidden cost of unused tables.
- New defaults. Gen2 warehouses use 1.25 to 1.35 times the credits per hour of Gen1, and Query Acceleration bills whenever it is used. Both are now on by default in many accounts.
- Spend nobody owns. Without query tags or cost attribution, nobody can see which team, pipeline or dashboard is driving the bill, so nobody fixes it. AI spend is the newest example, and resource monitors do not cover it.
When the bill jumps suddenly, start with why your Snowflake bill doubled and how to trace a cost spike to the query and the person who ran it.
17 ways to reduce Snowflake costs
The techniques below are grouped by where the money goes. Start with warehouses: they are usually the largest part of the bill, and idle time can be cut with no effect on query performance.
Warehouses
1. Right-size your warehouses. Start with the smallest size that meets your performance target and move up only if queries get meaningfully faster. Each size up doubles the credits per hour, so a warehouse one size too big costs twice as much for the same work unless queries finish twice as fast.
CREATE WAREHOUSE my_small_wh
WAREHOUSE_SIZE = 'XSMALL'
AUTO_SUSPEND = 60 -- suspend after 60 seconds of inactivity
AUTO_RESUME = TRUE;
New standard warehouses are Gen2 unless you say otherwise. See Snowflake warehouse sizes and credits per hour.
2. Consolidate warehouses. Many small warehouses that are each busy for a few minutes an hour pay for more idle time and more 60-second minimums than one shared warehouse. Move compatible workloads, such as reporting tasks, onto a shared, right-sized warehouse.
CREATE WAREHOUSE shared_reporting_wh
WAREHOUSE_SIZE = 'MEDIUM'
AUTO_SUSPEND = 120
AUTO_RESUME = TRUE;
-- Point each task at the shared warehouse.
-- A started task must be suspended before it can be modified.
ALTER TASK monthly_sales_report_task SUSPEND;
ALTER TASK monthly_sales_report_task SET WAREHOUSE = shared_reporting_wh;
ALTER TASK monthly_sales_report_task RESUME;
3. Set AUTO_SUSPEND to fit the workload. The default of 600 seconds suits few workloads. Lower it on warehouses with bursty use so they stop billing soon after the last query. Do not set it so low that a warehouse woken every few seconds pays the 60-second minimum over and over.
ALTER WAREHOUSE my_small_wh
SET AUTO_SUSPEND = 120 AUTO_RESUME = TRUE;
4. Choose Gen1 or Gen2 per workload. Gen2 costs 1.35 times as much per hour on AWS and GCP and 1.25 times on Azure, so it only saves money when queries run at least 26% faster on AWS and GCP, or 20% faster on Azure. It tends to help DML-heavy and scan-heavy work. Test it per warehouse rather than switching everything. See Gen1 vs Gen2 warehouses.
5. Control multi-cluster scaling. Each running cluster bills at the full rate for its size. Set MAX_CLUSTER_COUNT to what the workload really needs, and consider SCALING_POLICY = ‘ECONOMY’ where some queuing is acceptable: it starts a new cluster only when there is enough work to keep it busy for at least 6 minutes.
CREATE WAREHOUSE analytics_wh
WAREHOUSE_SIZE = 'LARGE'
MAX_CLUSTER_COUNT = 3
AUTO_SUSPEND = 300
AUTO_RESUME = TRUE
SCALING_POLICY = 'STANDARD';
6. Review Query Acceleration. The Query Acceleration Service lends a warehouse extra compute for outlier queries, billed separately whenever it is used. It needs Enterprise Edition and is now on by default for new Gen2 warehouses. Check what it costs and turn it off where it does not earn its keep.
-- QAS credits per warehouse, month to date
SELECT warehouse_name, SUM(credits_used) AS qas_credits
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_ACCELERATION_HISTORY
WHERE start_time >= DATE_TRUNC('MONTH', CURRENT_DATE)
GROUP BY warehouse_name
ORDER BY qas_credits DESC;
-- Turn it off for one warehouse
ALTER WAREHOUSE reporting_wh SET ENABLE_QUERY_ACCELERATION = FALSE;
More on warehouses: how to automate Snowflake warehouse optimization.
Queries and pipelines
7. Reuse cached results. Snowflake keeps query results for 24 hours and returns them without running the query again if the same query comes back and the data has not changed. Reuse needs an exact match, so dashboards that send identical SQL benefit most. When you benchmark a change, turn reuse off for your session so you measure real execution:
ALTER SESSION SET USE_CACHED_RESULT = FALSE;
8. Select and filter only what you need. Reading every column and filtering late makes Snowflake scan more data than the answer needs.
-- Costly: reads every column and every row
SELECT * FROM orders;
-- Cheaper: only the columns needed, filtered early
SELECT order_id, order_date, total_amount
FROM orders
WHERE order_date >= CURRENT_DATE - INTERVAL '30 days';
9. Help pruning, and cluster only where it pays. Snowflake skips micro-partitions that cannot match a query’s filters. On very large tables that are filtered the same way again and again, a clustering key can make that pruning far more effective. Clustering has a running cost, so check what your clustered tables cost before adding another key:
SELECT table_name, SUM(credits_used) AS clustering_credits
FROM SNOWFLAKE.ACCOUNT_USAGE.AUTOMATIC_CLUSTERING_HISTORY
WHERE start_time >= DATEADD(DAY, -30, CURRENT_TIMESTAMP())
GROUP BY table_name
ORDER BY clustering_credits DESC;
See auto-clustering costs out of control?
10. Cap runaway queries. By default a statement can run for up to two days before Snowflake cancels it. Set STATEMENT_TIMEOUT_IN_SECONDS on warehouses that serve interactive work, so one bad query cannot run for hours.
ALTER WAREHOUSE reporting_wh SET STATEMENT_TIMEOUT_IN_SECONDS = 3600;
See Snowflake query timeouts can break the bank.
11. Retire pipelines nobody uses. Tasks and scheduled jobs often keep running after their consumers are gone. This query lists started tasks that have not succeeded in the past 30 days:
SELECT task_database, task_schema, task_name, last_success
FROM (
SELECT t.task_database, t.task_schema, t.task_name,
MAX(IFF(h.state = 'SUCCEEDED', h.completed_time, NULL)) AS last_success
FROM SNOWFLAKE.ACCOUNT_USAGE.TASKS t
LEFT JOIN SNOWFLAKE.ACCOUNT_USAGE.TASK_HISTORY h
ON h.database_name = t.task_database
AND h.schema_name = t.task_schema
AND h.name = t.task_name
WHERE t.deleted IS NULL
AND t.state = 'started'
GROUP BY t.task_database, t.task_schema, t.task_name
)
WHERE last_success IS NULL
OR last_success < DATEADD(DAY, -30, CURRENT_TIMESTAMP());
Confirm with the owning team, then suspend before you drop: ALTER TASK my_etl_task SUSPEND. For dbt projects, see how to reduce the Snowflake cost of your dbt models.
Storage and serverless features
12. Set Time Travel retention deliberately. Every changed or deleted row is kept for the Time Travel period, then 7 days of Fail-safe on permanent tables, and all of it is billed as storage. Keep long retention for tables that need it and lower DATA_RETENTION_TIME_IN_DAYS on large tables that are rewritten often.
13. Use transient tables for data you can rebuild. Transient tables have no Fail-safe and at most 1 day of Time Travel, so staging and intermediate tables cost less to keep.
14. Clone instead of copying. A zero-copy clone uses no extra storage when it is created; it costs only as it and the source diverge. Use clones for test and development copies instead of full copies.
CREATE TABLE sales_data_clone CLONE sales_data;
15. Review materialized views, search optimization and clustering. All three keep billing in the background whenever their tables change, even if nobody queries them any more. Suspend reclustering or drop clustering keys, search optimization and materialized views that no longer pay off. See what Snowflake serverless features cost.
Ownership and guardrails
16. Tag queries and attribute cost. Set a query tag per pipeline, tool or team, then group the compute Snowflake attributes to each query by tag. Once costs have owners, they get fixed.
ALTER SESSION SET QUERY_TAG = 'etl_orders_daily';
SELECT query_tag,
SUM(credits_attributed_compute) AS compute_credits,
SUM(credits_used_query_acceleration) AS acceleration_credits
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_ATTRIBUTION_HISTORY
WHERE start_time >= DATEADD(DAY, -30, CURRENT_TIMESTAMP())
GROUP BY query_tag
ORDER BY compute_credits DESC;
QUERY_ATTRIBUTION_HISTORY leaves out warehouse idle time and queries of about 100 milliseconds or less. See our guides to query tags and cost per query attribution.
17. Limit who can use big warehouses, and set limits. A role can only run queries on a warehouse it has USAGE on, so give analyst roles a right-sized shared warehouse rather than your largest one. Then set a resource monitor to warn or suspend a warehouse at a credit limit, and a budget for serverless features and AI services, which resource monitors do not cover.
GRANT USAGE ON WAREHOUSE shared_reporting_wh TO ROLE analyst_role;
See Snowflake resource monitors.
How do you cut Snowflake costs without slowing down your pipelines?
Change one thing at a time and measure it. Many savings carry no performance risk at all, and the ones that do can be tested before they are rolled out.
- Cut idle time first. Shorter suspend times, fewer lingering clusters and retired pipelines save money without touching how fast any query runs.
- Measure before and after. Record runtime (including the slow tail, not just the average), queuing and spilling for a warehouse before you resize it, then compare after.
- Downsize in steps. Move down one size at a time and watch for queuing or spilling to disk. Move back up if they appear.
- Test Gen2 per warehouse. Keep it only where runtimes drop by more than the 25 to 35% price premium.
- Use timeouts as a safety net, not as a way to save money on healthy queries.
How do you keep Snowflake costs down?
Costs drift back up as workloads, teams and defaults change. A light routine keeps them in check:
- Weekly: look at the bill by service type and by warehouse, and check anything that moved.
- On every spike: trace it to the query, user or pipeline behind it.
- Monthly: review clustering, materialized views, search optimization and unused tables.
- Before renewal: check how much of your capacity you will have used by the end of the term, months before it ends. See our 90-day plan before a Snowflake renewal and contract planning guide.
Snowflake’s own cost management area in Snowsight shows spend by account, warehouse and service. Budgets send a notification when spending passes a limit, including for serverless features and AI.
Doing it by hand or automating it
Every technique in this guide can be done by hand, and the SQL above is a good start. The limits are time and change: usage patterns shift hour by hour, idle seconds add up across hundreds of warehouses, and a size that was right last month can be wrong today.
That is the gap Seemore fills. SmartPulse turns each warehouse’s real usage pattern into an hourly plan, downsizing through quiet hours, scaling back up for recurring peaks, and recommending Gen1 or Gen2 alongside size. Auto-Shutdown suspends each warehouse the moment it goes idle instead of waiting out a fixed timeout, and Auto-Scaler scales extra clusters down the moment they stop earning their keep, without touching running queries. Cost Anomaly Detection and Contract Utilization tell you when spend drifts and where you are heading against your contract. See how the Seemore platform handles Snowflake cost optimization.
Snowflake cost optimization guides
- Understand the bill: Snowflake pricing explained · how much is a Snowflake credit · warehouse sizes and credits per hour · serverless feature costs · storage costs
- Warehouses: automating warehouse optimization · Gen1 vs Gen2 · Adaptive Warehouses
- Find who is spending: cost per query · query tags · chargeback vs showback · why your bill doubled
- AI costs: Snowflake Cortex AI costs
- Tools: best Snowflake cost management tools
Frequently asked questions
What are the biggest drivers of Snowflake costs?
Snowflake costs are primarily driven by compute (virtual warehouses and serverless services), storage (active data, Time Travel, Fail-safe), and data transfer (cross-region or cross-cloud movement).
How do virtual warehouses impact Snowflake compute costs?
Virtual warehouses consume credits per second based on size and active time. Over-sized or idle warehouses are the most common source of unnecessary spend.
Is Snowflake Gen2 more cost-effective than Gen1?
Only when queries finish fast enough to cover its higher rate. Gen2 uses 1.35 times the credits per hour on AWS and GCP and 1.25 times on Azure, so it saves money only when runtimes drop by at least 26% or 20% respectively.
How does Time Travel affect Snowflake storage costs?
Time Travel stores historical versions of data for the retention period. Longer retention increases storage usage because each data change preserves previous versions.
When should I use transient or temporary tables in Snowflake?
Use transient tables for regenerable data that needs short Time Travel and no Fail-safe. Use temporary tables for session-scoped data to avoid long-term storage costs.
Do materialized views always reduce Snowflake costs?
No. Materialized views reduce compute for repeated queries but add storage and maintenance costs. They are cost-effective only for expensive, frequently reused queries.
How does query design influence Snowflake cost optimization?
Poor query design increases scanned data and execution time. Selecting only required columns, filtering early, and leveraging pruning directly reduces compute usage.
How can teams attribute Snowflake costs to users or workloads?
Query tagging enables cost attribution by labeling queries with metadata, allowing teams to analyze usage and spend by user, team, or application.
What is the quickest win in Snowflake cost optimization?
Cut idle warehouse time. Lowering AUTO_SUSPEND on bursty warehouses, retiring unused pipelines and scaling extra clusters down saves money without changing how fast any query runs. Right-sizing oversized warehouses usually comes next.
Where should Snowflake cost optimization start?
Split the bill by service type with METERING_DAILY_HISTORY, then by warehouse with WAREHOUSE_METERING_HISTORY, then by query, user or tag with QUERY_ATTRIBUTION_HISTORY. That tells you which warehouses, pipelines and teams to look at first.
Does Snowflake have built-in cost controls?
Yes. Resource monitors can warn about or suspend warehouses at a credit limit, budgets cover serverless features and AI services too, and the cost management area in Snowsight shows spend by account, warehouse and service.