10 ways to optimize (and reduce) your Snowflake spend in 2025

Let's face it—Snowflake costs can sneak up on you. One day you're celebrating the power and flexibility of your data warehouse, and the next you're explaining to leadership why this month's bill is double what you forecasted.

As data engineers, we're caught in the middle: we need to provide powerful analytics capabilities for our organizations while keeping costs under control. I've seen teams struggle with this balancing act, which is why I've put together this guide based on real-world experience and best practices.

Understanding what components make up your Snowflake cost

Before diving into optimization strategies, let's break down what you're actually paying for.

Snowflake’s pricing model includes three main categories: compute resources, storage costs, and data transfer. Each category has unique characteristics affecting the total cost.

Compute Resources: A significant portion of Snowflake costs stems from compute resources, particularly virtual warehouses. These virtual warehouses execute queries and load data, operating independently, which means their usage patterns can significantly affect the monthly bill.

Storage Costs: Storage fees are another critical component. The typical storage cost per terabyte (TB) is about $23, but this can vary depending on the region and account type. Effective management of data storage can lead to substantial savings.

Data Transfer: Although data ingress (upload) into Snowflake is free, data egress (download) across regions incurs charges. Understanding these costs is crucial for optimizing Snowflake spend.

Let’s dive a bit deeper into each one.

Compute Resources

Compute resources are central to Snowflake’s data processing. They’re also typically where most of your bill comes from. Virtual warehouses execute queries and load data, with costs varying based on:

- Warehouse size: From XS ($2/credit) to 4XL+ ($128/credit)

- Running time: Per-second billing with a 60-second minimum

- Credit costs: Ranging from $2.50 to $6.50 depending on your plan

- Concurrency: Multi-cluster warehouses spinning up additional resources

The key insight here: an idle warehouse is literally burning money. Those warehouses running longer than needed for "just in case" scenarios? They're quietly draining your budget.

Rewriting queries and restricting access to larger warehouses are effective strategies. Optimizing query logic and controlling warehouse size can significantly reduce unnecessary compute costs. The pay-per-second pricing model, with credit costs from $2.50 to $6.50, highlights the need for careful management.

Resource monitors can help track and limit warehouse usage. Setting up resource monitors to alert on excessive usage or automatically suspend idle warehouses can prevent runaway costs and improve cost efficiency.

Understanding and managing compute resources is key to optimizing Snowflake spend. These strategies help control costs and ensure efficient resource use.

Storage costs

Storage costs in Snowflake are more predictable, but they can still sneak up. Here’s how it works:

• Standard rate: ~$23 per TB per month (varies by region)
• Time-travel and fail-safe storage: Additional costs for keeping historical data
• Regional variations: Can reach $50.50/TB in Zurich or $40/TB in Washington

A quick calculation: 10TB of data in EST of the US = ~$230/month. It’s not bank-breaking, but it scales with your data footprint, hence how it sneaks up.

Frequent data load operations can increase storage consumption and overall costs. Managing data load frequency and volume is important for cost optimization. Tracking storage usage and minimizing unnecessary data can significantly reduce costs.

Data transfer

Data transfer costs in Snowflake are incurred when moving data across regions within the same cloud platform. These charges are based on a per-byte fee and can vary by region.

Data transfer costs are often overlooked until they surprise you on the bill. Here’s how it works:

• Inbound data: Free (a rare freebie in cloud services)
• Cross-region transfers: Pay per byte moved
• Outbound data: Charges apply when moving data out

Understanding and efficiently planning data transfers can help manage and control overall Snowflake spend. Minimizing unnecessary data movement and leveraging Snowflake’s features can optimize data transfer processes.

Best practices for optimizing your Snowflake spend and reducing costs

Once you understand where your Snowflake costs come from, you can start implementing strategies to optimize them. Here are the most effective ways to cut down on unnecessary spending:

Set up resource monitors (your first line of defense)

Resource monitors are non-negotiable for cost management. Think of them as the circuit breakers in your Snowflake house. I've seen teams burn through their entire quarterly budget in a single weekend because of a runaway query—without monitors, you're flying blind.

Here's a basic monitor that will save you countless headaches:

```sql

CREATE OR REPLACE RESOURCE MONITOR monthly_limit

WITH CREDIT_QUOTA = 1000

FREQUENCY = MONTHLY

START_TIMESTAMP = IMMEDIATELY

TRIGGERS ON 75 PERCENT DO NOTIFY

         ON 90 PERCENT DO NOTIFY

         ON 100 PERCENT DO SUSPEND;

```

Take it up a notch by setting separate monitors for different environments. For critical production workloads, consider using `SUSPEND_IMMEDIATE` at 100% instead of just `SUSPEND`—this prevents half-completed queries from consuming extra credits. Create more aggressive monitors for development warehouses (50/75/90%) to catch issues early.

Implement auto-suspend and auto-resume (stop paying for idle time)

The default auto-suspend in Snowflake is 5 minutes—in the cloud world, that's an eternity of burning money for nothing. A single medium warehouse left running idle costs ~$2/hour. Multiply that across multiple warehouses, and you're looking at thousands in waste annually.

This simple change makes a huge difference:

```sql

ALTER WAREHOUSE analytics_wh

SET AUTO_SUSPEND = 60;

```

For development or intermittent-use warehouses, you can be even more aggressive (30 seconds). For BI tools that have constant but sporadic queries, you'll want to find the sweet spot between frequent suspend/resume overhead and idle time. Keep an eye on your warehouse "cold start" frequency—if users complain about slowness, you might need to balance auto-suspend time with user experience.

Changing from 5 minutes to 1 minute can save you serious money on your compute bill.

Right-size your warehouses (stop overprovisioning)

Bigger isn't always better. Too many teams default to XL or larger warehouses for everything, burning money with minimal performance gains. Each warehouse size doubles the cost—rightsizing can literally cut your bill in half while maintaining nearly identical performance.

For BI dashboards and reporting, start with XS/S and only scale up if you consistently hit >60% resource utilization. For ELT processes, test representative loads at different sizes to find the sweet spot (often M). For data science workloads, consider dedicated warehouses that scale up when needed and down when idle.

Want to get scientific about it? Use the `QUERY_HISTORY` view to analyze your patterns:

```sql

SELECT WAREHOUSE_SIZE, 

       AVG(EXECUTION_TIME)/1000 as AVG_EXECUTION_SECONDS,

       COUNT(*) as QUERY_COUNT

FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY

WHERE START_TIME > DATEADD(month, -1, CURRENT_TIMESTAMP())

AND WAREHOUSE_NAME = 'ANALYTICS_WH'

GROUP BY WAREHOUSE_SIZE

ORDER BY AVG_EXECUTION_SECONDS;

```

This helps you quantify the actual performance difference between sizes for your specific workloads. If there isn’t a noticeable difference in performance, downsize and save.

Master query caching effectively

Snowflake's 24-hour result cache is magical when used correctly. The best part? You don't pay compute credits for cached results. Teams that structure their queries for caching can see huge reductions in compute costs with little to no performance loss.

Standardize dashboard queries to use identical SQL patterns whenever possible. Use parameterized queries in your BI tools—different parameter values still use the cache. Avoid cache-busting patterns like `CURRENT_TIMESTAMP()` or other volatile functions, `RANDOM()` or non-deterministic functions, and session-specific variables that change query signatures.

For operations that require fresh data but have expensive joins/aggregations, try this two-step approach:

```sql

-- Step 1: Materialized fresh data in temp table

CREATE OR REPLACE TEMPORARY TABLE fresh_daily_sales AS

SELECT * FROM sales WHERE date = CURRENT_DATE();

‍

-- Step 2: Join with expensive but unchanging dimensions (this can be cached!)

SELECT d.region, d.product_category, SUM(s.amount)

FROM fresh_daily_sales s

JOIN dim_product d ON s.product_id = d.product_id

GROUP BY 1, 2;

```

Implement query timeouts to prevent runaway queries

We've all been there—you write a query, hit execute, and suddenly realize you forgot a `WHERE` clause on a billion-row table. Query timeouts are your safety net. A single runaway query can consume hundreds or thousands of credits before someone notices and kills it.

Set reasonable timeouts at different levels depending on your needs:

Account-wide default (requires admin):

```sql

ALTER ACCOUNT SET STATEMENT_TIMEOUT_IN_SECONDS = 14400; -- 4 hours max

```

Per-user setting (great for new team members):

```sql

ALTER USER dataengineer SET STATEMENT_TIMEOUT_IN_SECONDS = 600; -- 10 minutes

```

Or per-session (useful in development):

```sql

ALTER SESSION SET STATEMENT_TIMEOUT_IN_SECONDS = 600;

```

Different user types need different timeouts. For analysts and BI users, 5-15 minutes is usually sufficient. Data engineers running batch processes might need 30-60 minutes. Data scientists typically need around 30 minutes for interactive queries, longer for scheduled jobs.

Use shorter timeouts during development, longer ones in production. Most bad queries show themselves quickly—better to fail fast and fix than to let them drain your credits.

Leverage data observability for cost insights

Data observability tools (like Metaplane!) help you peek into the black box of credit consumption. With our Spend Analysis feature, you can immediately see your daily total credit spend, a 30-day spend aggregation, and your daily spend broken down by warehouse and user.

Warehouse and user-level credit consumption helps identify which teams or processes are driving costs. Query pattern analysis finds optimization opportunities in repeatedly executed expensive queries.

Metaplane’s spend analysis dashboard is powered by the same machine learning capabilities that power the rest of our monitors. This can help you catch and understand abnormal spikes or drops in credit usage. Your team will be able to:

Capture upstream issues: For example, a misfiring pixel could lead to thousands of duplicate events in a table, directly increasing the length and credit usage of a modeling query merging that table. This is the sort of spike the spend analysis tool is made to capture.

Confirm proper Snowflake configuration(s): Imagine that your team updated the `AUTO_SUSPEND` setting, but accidentally added an extra “0”, leading to longer active warehouses, and higher spend for that warehouse. Catching an issue like this is a perfect use case for spend analysis monitoring.

Set up regular optimization efforts: Incorporate the dashboard into your optimization workflow to understand the largest contributors towards your Snowflake spend and discuss if those contributors are worth reviewing.

Improve Total Cost of Ownership for your whole data stack: By splitting out credit usage by users and warehouses, your team is able to better understand which service accounts and/or “service” compute resources should be targeted for efficiency gains.

You can even use our Snowflake native app to get started—paid for by all the credits you save as a result of this article.

Master zero-copy cloning for test environments

Zero-copy cloning is one of Snowflake's superpowers, yet so many teams don't use it. Creating full copies of databases for testing or development can double or triple your storage costs. Zero-copy cloning gives you identical environments with minimal additional storage.

It's incredibly simple to implement:

For databases:

```sql

CREATE DATABASE dev_db CLONE prod_db;

```

For individual tables:

```sql

CREATE TABLE analytics.customers_test CLONE analytics.customers;

```

You can take this further with short-lived clones for testing:

```sql

CREATE TEMPORARY TABLE destructive_test CLONE production.important_table;

```

Or use clones for point-in-time analysis:

```sql

CREATE TABLE finance.month_end_snapshot 

CLONE finance.transactions BEFORE (TIMESTAMP => 'YYYY-MM-DD 23:59:59');

```

For the truly ambitious, create automated weekly refreshes of development environments:

```sql

CREATE TASK refresh_dev_weekly

WAREHOUSE = maintenance_wh

SCHEDULE = 'USING CRON 0 0 * * SUN America/Los_Angeles'

AS

BEGIN

  CREATE OR REPLACE DATABASE dev_db CLONE prod_db;

END;

```

Implement custom budgets for departments and teams

If you want to change spending behavior, make it visible. Custom budgets transform abstract "cloud costs" into tangible metrics teams care about. Cost management works best when it's decentralized and visible.

Create separate warehouses for different teams or functions, set up custom budgets with alerts using resource monitors, and share daily spend digests with team leads. When people see the costs associated with their work, behavior naturally shifts toward efficiency.

Want to get fancy with cost attribution? Try query tagging:

```sql

-- First, set up a session context variable

ALTER SESSION SET QUERY_TAG = 'department=marketing,project=campaign_analysis';

‍

-- Then query the history to allocate costs

SELECT split_part(QUERY_TAG, 'department=', 2) as DEPARTMENT,

       sum(CREDITS_USED) as CREDITS

FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY

WHERE START_TIME > DATEADD(month, -1, CURRENT_TIMESTAMP())

AND QUERY_TAG IS NOT NULL

GROUP BY 1

ORDER BY 2 DESC;

```

If you wanted to get really serious about it, you could create friendly competition with monthly leaderboards showing "most efficient queries" and "biggest cost savings." Winners get a deviled egg bar, maybe?

Implement smart storage management

Storage might seem cheap compared to compute, but it compounds over time—especially with time travel and fail-safe retention.

Start with appropriate retention periods:

```sql

ALTER TABLE large_logs SET DATA_RETENTION_TIME_IN_DAYS = 30;

```

Use transient tables for temporary data:

```sql

CREATE TRANSIENT TABLE staging.import_buffer (data VARIANT);

```

Implement automated cleanup:

```sql

CREATE TASK cleanup_old_data

WAREHOUSE = maintenance_wh

SCHEDULE = 'USING CRON 0 0 * * * America/Los_Angeles'

AS

DELETE FROM logs.api_events WHERE event_date < DATEADD(days, -90, CURRENT_DATE());

```

Finding your storage hogs is half the battle. This query quickly shows you where to focus:

```sql

SELECT table_catalog, 

       table_schema,

       table_name,

       active_bytes / (1024*1024*1024) as active_storage_gb,

       time_travel_bytes / (1024*1024*1024) as time_travel_gb,

       failsafe_bytes / (1024*1024*1024) as failsafe_gb,

       (active_bytes + time_travel_bytes + failsafe_bytes) / (1024*1024*1024) as total_gb

FROM snowflake.account_usage.table_storage_metrics

ORDER BY total_gb DESC

LIMIT 20;

```

Consider a data tiering strategy. Keep hot data in standard tables, move warm data (3+ months old) to tables with shorter retention, and archive cold data (1+ year old) with COPY INTO @stage commands to S3/blob storage. 

Build a cost-conscious engineering culture

Technical solutions only go so far. The most sustainable cost savings come from building a team culture that values efficiency.

Make costs visible with dashboards in common areas. Include "efficiency impact" in code reviews. Create a #snowflake-optimization Slack channel to share wins. Celebrate cost reductions with the same enthusiasm as feature launches. Incorporate cost efficiency into team OKRs.

Develop a "Snowflake Cost Efficiency" onboarding module for all new data team members covering how to use `EXPLAIN PLAN` to analyze query performance, query optimization techniques specific to Snowflake, warehouse sizing guidelines, resource monitor usage, and how to use the query history to audit your own impact.

The ROI on cultural change can be massive—often dwarfing the gains from any single technical optimization.

Snowflake spend management FAQs

1. What is the biggest contributor to Snowflake costs?

The largest cost driver is typically compute (virtual warehouses), which charges per-second usage based on the size and activity of the warehouse.

2. How can I reduce compute costs in Snowflake?

Use auto-suspend, optimize queries, right-size warehouses, and set up resource monitors to track usage.

3. What role does data observability play in cost management?

Data observability tools like Metaplane help monitor data quality, identify inefficiencies, and provide visibility into Snowflake spend to optimize usage and prevent waste.

4. How do I prevent unexpected Snowflake costs?

Set up spend alerts, enforce query limits, and regularly review usage patterns to catch cost anomalies before they become a problem.

5. Does Snowflake charge for storing old data?

Yes, Snowflake charges per terabyte for storage, so managing retention policies and removing unnecessary data can help reduce costs. 

Final thoughts

Managing Snowflake costs doesn't require massive architecture changes. Often, the biggest savings come from small, consistent optimizations and building visibility into your spending patterns.

The key is balancing performance needs with cost efficiency—and having the right tools to make informed decisions. With resource monitors as your guardrails, proper warehouse sizing as your foundation, and data observability tools like Metaplane providing insights, you can get the most value from your Snowflake investment without breaking the bank.

Want to learn how to use Metaplane to not only track your Snowflake cost, but monitor your data across your entire pipeline? Talk to our team.