Snowflake Cost Optimization: Top 17 Techniques in 2026

What Is Snowflake Cost Optimization?

Snowflake is a popular cloud-based data warehouse service. Snowflake cost optimization is the process of identifying and implementing strategies to reduce expenses while using the Snowflake data platform. Snowflake costs can accumulate from compute resources, storage, and data transfer. Optimizing costs ensures the platform is used efficiently, without sacrificing performance or functionality. Learn how to optimize snowflake warehouse in 2026, automatically. Cost optimization on Snowflake involves analyzing usage patterns, evaluating inefficiencies, and applying best practices. With Snowflake’s consumption-based pricing model, users must create cost-effective query designs and limit unnecessary data processing. By understanding and addressing cost drivers, users can maximize value without exceeding budgets. This is part of a series of articles about Snowflake pricing.

In this article, we’ll cover the following Snowflake cost optimization techniques:

• Optimizing Compute Resources
• Efficient Storage Management
• Query Performance Tuning
• Monitoring and Managing User Activity
• Implementing Data Compression and Partitioning
• Query Acceleration

Key Factors Driving Snowflake Costs

Before diving into cost optimization techniques, it’s important to understand the main cost drivers when using Snowflake.

Compute Costs: Virtual Warehouses

Snowflake Gen1

Snowflake Gen1 standard warehouses charge based on a fixed credit rate tied to warehouse size. Billing is calculated per second, with a 60-second minimum whenever a warehouse starts. Credits double with each size step: a Medium warehouse uses 4 credits per hour, a Large uses 8, and so on up to 512 credits per hour for a 6X-Large. (Snowflake Service Consumption Table, Table 1(a)) For example, running an X-Small warehouse for exactly 10 minutes costs approximately 0.167 credits, while a 5X-Large for the same duration costs over 42 credits. Snowflake’s per-second billing helps minimize idle time costs, and auto-suspend/resume features further help reduce unnecessary usage. Using multi-cluster warehouses, which are available in Enterprise Edition, adds another layer of scalability. Billing then depends on both the size of the warehouse and the number of concurrently active clusters. For example, a 3X-Large warehouse running two clusters for one hour would consume 128 credits (64 per cluster). Larger warehouses don’t always equate to faster performance, especially for tasks like data loading, which are more sensitive to file count and size than compute capacity. Snowflake’s own guidance is that, unless you are bulk loading hundreds or thousands of files at once, a smaller warehouse is generally sufficient, because a larger one consumes more credits and may not improve performance. (Snowflake documentation)

Snowflake Gen2

Gen2 standard warehouses run on newer hardware with software optimizations aimed at DML (DELETE, UPDATE, MERGE) and table scans. They use more credits per hour than Gen1: 1.35 times as many on AWS and GCP, and 1.25 times as many on Azure. (Service Consumption Table, Table 1(b)) Despite the higher rate, Gen2 can be more cost-efficient for long-running or DML-heavy workloads, because a query that finishes faster is billed for fewer seconds. The break-even is a runtime cut of at least 26% on AWS and GCP, or 20% on Azure.

Gen2 is available on AWS, Azure and GCP in nearly every region, and since Snowflake’s 2026_03 behavior change it is the default for every new standard warehouse (before that, the default depended on region and organization age), so a CREATE WAREHOUSE with no GENERATION value bills at the Gen2 rate. (Snowflake documentation) Gen2 is not available for the largest sizes, X5LARGE and X6LARGE, so a workload on those sizes has to be tested on a smaller size first.

The key to maximizing Gen2’s cost-efficiency is workload fit. In one Seemore customer test on a merge-heavy warehouse, we saw a 35% improvement in p95 query runtime, but no significant change in total uptime or concurrency handling. Cost increases of up to 5% were observed on some days, highlighting the need for ongoing monitoring. Switching an existing warehouse takes one statement, ALTER WAREHOUSE my_wh SET GENERATION = '2', with no change to your SQL. (Snowflake’s 2026_02 behavior change stops accepting the older RESOURCE_CONSTRAINT setting for this.) For the full test and the cost break-even, see our Gen2 deep dive.

Storage Costs

Storage costs in Snowflake are influenced by the amount of data retained in databases, including staged files, backups, and historical data maintained for recovery purposes. While Snowflake automatically compresses data, large volumes of unused or redundant data can still lead to higher expenses. Retaining obsolete datasets or failing to enforce data retention policies often results in inflated storage fees that could otherwise be mitigated. A significant contributor to storage costs is Snowflake’s Continuous Data Protection (CDP) features, specifically Time Travel and Fail-safe.

Time Travel allows access to historical data for a specified retention period. The default retention period is 1 day, but it can be configured up to 90 days for Enterprise Edition accounts. Longer retention periods result in more historical data being stored, increasing storage costs. Whenever data in a table is modified or deleted, Snowflake preserves the previous version, which adds storage. The retention period can be set at the account, database, schema, or table level using the DATA_RETENTION_TIME_IN_DAYS parameter.

Fail-safe provides a non-configurable 7-day period following the Time Travel retention period, during which Snowflake can recover historical data in the event of a system failure or other catastrophic event. This data is not accessible to users and is intended solely for Snowflake’s internal recovery processes. Data in Fail-safe continues to incur storage costs until the period expires.

Table Types and Their Impact on Storage Costs

Snowflake offers different table types that affect how Time Travel and Fail-safe apply:

• Permanent Tables: Support Time Travel (up to 90 days) and have a 7-day Fail-safe period. Suitable for long-lived data requiring full recovery options.
• Transient Tables: Support Time Travel (0 or 1 day) but do not have a Fail-safe period. Ideal for data that can be regenerated and does not require long-term recovery.
• Temporary Tables: Exist only for the duration of a session and do not support Fail-safe. Best for short-lived, session-specific data.

(Snowflake documentation: Time Travel, Fail-safe)

Data Transfer Costs

Data transfer costs occur when data is moved in or out of Snowflake, or between different regions and clouds. These costs are especially relevant for cross-region replication and hybrid workloads. While transferring data is essential for operations such as disaster recovery or multi-region analytics, excessive or inefficient transfers can increase bills significantly.

Optimizing data transfer costs requires careful planning. Consider reducing unnecessary replication operations, consolidating cloud regions, or using Snowflake’s native data sharing features instead of direct transfers. Additionally, monitoring and analyzing usage patterns can help identify areas where data movement can be minimized.

Snowflake Services

Beyond compute, storage, and data transfer, Snowflake offers several managed services that can incur additional costs. These services are billed based on usage and are designed to provide additional functionality without requiring users to manage infrastructure.

Serverless Features

Snowflake provides serverless compute options for specific tasks, such as:

• Snowpipe: Automates continuous data ingestion.
• Materialized Views: Stores precomputed query results for faster access.
• Search Optimization Service: Enhances query performance on selective filters.

These services consume credits and are managed by Snowflake, which scales them automatically with workload demand. Unlike virtual warehouses, which are user-managed, serverless features bill on their own meters, and the basis differs by feature. Materialized views and the search optimization service are billed for the serverless compute they use. Snowpipe is billed per gigabyte ingested (0.0037 credits per GB; text files count at their uncompressed size, binary files like Parquet at their stored size), with no per-file charge. (Snowflake documentation: Snowpipe billing)

Cloud Services Layer

The cloud services layer encompasses various functions that coordinate activities across Snowflake, including:

• Authentication and Security: Managing user access and enforcing security policies.
• Metadata Management: Handling schema definitions, query parsing, and optimization.
• Infrastructure Coordination: Orchestrating operations across compute and storage layers.

Cloud services usage is charged only if the daily consumption of cloud services exceeds 10% of the daily usage of your virtual warehouses. It can still add up in scenarios involving:

• High-frequency metadata operations (e.g., frequent DDL statements).
• Complex query compilations.
• Frequent use of administrative commands or third-party tools that interact with metadata.

Monitoring and optimizing interactions with the cloud services layer can help manage these costs. (Snowflake documentation: understanding compute cost)

Snowpark Container Services

Snowpark Container Services allow users to run containerized applications and services within Snowflake’s environment. Costs associated with these services include:

• Compute Pool Costs: Based on the number and type of virtual machine nodes allocated.
• Storage Costs: For container images, logs, and any data stored within the service.
• Data Transfer Costs: For data moving in and out of the container services, including internal transfers within Snowflake.

Top Techniques for Snowflake Cost Optimization

Optimizing Compute Resources

Snowflake compute costs are a key factor in determining your overall cost when using Snowflake. Fortunately, optimizing your virtual warehouse usage by right-sizing resources and leveraging automation can reduce these costs.

1. Right-Sizing Virtual Warehouses

Many new Snowflake users default to larger virtual warehouses, but allocating more resources than necessary leads to over-provisioning, where you pay for unused power. This can drive up your Snowflake compute costs without you realizing it. To avoid this, start with a smaller warehouse and scale up as needed.

Example: Create a smaller virtual warehouse.

CREATE WAREHOUSE my_small_wh
  WAREHOUSE_SIZE = 'XSMALL'
  AUTO_SUSPEND = 60  -- suspend after 60 seconds of inactivity
  AUTO_RESUME = TRUE;

A new standard warehouse is now Gen2 unless you say otherwise, and Gen2 bills 1.25 to 1.35 times the Gen1 rate. If you want Gen1, add GENERATION = '1'.

2. Consolidate Warehouses

Running too many separate virtual warehouses can increase costs due to idle compute and under-utilization. Consolidating workloads onto fewer, more appropriately sized warehouses improves efficiency by maximizing resource usage and simplifying management. Identify warehouses with overlapping activity or low utilization, migrate tasks and adjust resource configurations as needed.

Example: Move reporting tasks from multiple small warehouses to a shared medium 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;

If the task belongs to a task graph, suspend the root task first. (Snowflake documentation: ALTER TASK)

3. Auto-Suspend and Auto-Resume

Configuring auto-suspend to shut down warehouses when they’re not in use also helps reduce your Snowflake compute costs. You can use this alongside auto-resume, which restarts the warehouse when new queries are submitted. Together, these features ensure that you only pay for resources when needed and eliminate the need for manual intervention. Snowflake’s default is 600 seconds (10 minutes), and setting it to 0 or NULL is not recommended unless your workload needs a continually running warehouse. Keep in mind that each start or resume bills at least one minute, so on a warehouse that wakes up every few seconds a very short suspend time can cost more, not less. (Snowflake documentation: CREATE WAREHOUSE, understanding compute cost)

Example: Create a smaller virtual warehouse and use auto-suspend/resume to ensure you’re only paying for active time.

CREATE WAREHOUSE my_small_wh
  WAREHOUSE_SIZE = 'XSMALL'
  AUTO_SUSPEND = 60  -- suspend after 60 seconds of inactivity
  AUTO_RESUME = TRUE;

Example: Modify an existing warehouse to utilize auto-suspend/resume functionality.

ALTER WAREHOUSE my_small_wh
  SET AUTO_SUSPEND = 120 AUTO_RESUME = TRUE;

4. Identifying and Sunsetting Unused Pipelines

Unused pipelines can drive up costs by consuming resources while idle. You can identify inactive pipelines by regularly reviewing Snowflake’s query history and monitoring usage logs for low or no activity over time.

Example: To find inactive pipelines or scheduled tasks, list 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());

Before decommissioning, ensure that they’re not part of active workflows or scheduled processes by checking in with the relevant teams to confirm that they’re no longer needed. You can also temporarily deactivate them to avoid unintended disruptions and ensure that essential processes remain unaffected.

Example: Temporarily disable a task.

ALTER TASK my_etl_task SUSPEND;

Efficient Storage Management

Poor storage management can also lead to increased costs. This section outlines best practices for optimizing data retention and using cloning features to reduce expenses.

5. Data Retention Policies

It may be tempting to keep data just in case you need it later, but this can quickly increase your expenses. Instead, define retention periods that align with your regulatory requirements and business needs. Implement policies to automatically delete or archive data after the specified period, ensuring efficient storage management. Deleted data stays in Time Travel and then Fail-safe before the storage is released, so the saving appears only once those periods have passed.

Example: Automatically delete old rows.

DELETE FROM sales_data
WHERE transaction_date < DATEADD(YEAR, -2, CURRENT_DATE());

6. Cloning and Zero-Copy Cloning

Snowflake’s cloning feature lets you create copies of databases, schemas, or tables without physically duplicating the data. This is known as zero-copy cloning. Storage is only consumed when changes are made to the cloned object.

Example: Clone a full table without using extra storage.

CREATE TABLE sales_data_clone CLONE sales_data;

Query Performance Tuning

Snowflake query optimization directly impacts costs by reducing your cost per query. In this section, we’ll discuss two effective methods for enhancing query performance while minimizing resource consumption.

7. Utilize Result Caching

Snowflake automatically persists (caches) query results for 24 hours and checks for a reusable result before running a query again. If the same query comes back and the underlying data has not changed, Snowflake returns the stored result instead of executing the query. Each reuse resets the 24 hours, up to a maximum of 31 days from the first run. For example, if your dashboard displays sales data, caching speeds up queries when the data hasn’t changed, saving compute resources and reducing costs over time.

Reuse needs an exact match. A different table alias, or lowercase instead of uppercase keywords, will not reuse the result. Queries with non-reusable functions such as UUID_STRING or RANDOM, and queries on tables whose data has changed, run again. (Snowflake documentation: persisted query results)

Example: To confirm a query reused a result, open it in Snowsight’s Query Profile and look for a Query Result Reuse node. When you benchmark a change, turn reuse off for your session so you measure real execution:

ALTER SESSION SET USE_CACHED_RESULT = FALSE;

8. Optimize Query Design

Retrieving unnecessary data damages your Snowflake query optimization. This includes selecting all rows and columns when only some are needed, or applying filters too late. These practices cause Snowflake to process more data than necessary. Avoid this by selecting only the data you need and applying ‘WHERE’ clauses early to narrow down your dataset from the start.

Bad example:

SELECT * FROM orders;

Better example:

SELECT order_id, order_date, total_amount
FROM orders
WHERE order_date >= CURRENT_DATE - INTERVAL '30 days';

9. Implement Query Tagging for Cost Attribution

Query tagging allows you to assign metadata to SQL statements, making it easier to track and attribute costs to individual users, teams, or applications. A consistent tagging strategy helps analyze query performance and resource usage in the context of business units or projects. This helps in chargeback reporting, identifying high-cost activities, and improving accountability.

Example: Set a tag for a session before executing a query.

ALTER SESSION SET QUERY_TAG = 'etl_orders_daily';
SELECT * FROM transformed_sales_data;

You can then filter usage by query tag in the QUERY_HISTORY view to analyze compute resource consumption.

Example: Find all queries tagged with a specific label.

SELECT user_name, query_text, execution_time
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE query_tag = 'etl_orders_daily';

To see credits rather than runtime, group the compute cost Snowflake attributes to each query by tag. A query accelerated by the Query Acceleration Service has a second cost column, so the sample sums both. This view leaves out warehouse idle time, queries of about 100 milliseconds or less and Adaptive Warehouses, and it can lag by up to eight hours.

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;

(Snowflake documentation: QUERY_ATTRIBUTION_HISTORY)

Monitoring and Managing User Activity

Unmonitored user activity can cause unexpected cost spikes. In this section, we’ll examine how to implement stricter access controls and monitor usage to prevent inefficient or unauthorized operations.

10. Role-Based Access Control (RBAC)

Using role-based access control (RBAC) ensures that users access only the resources necessary for their role. This prevents them from accidentally triggering resource-intensive (i.e., expensive) operations. For cost, the most direct lever is the warehouse: a role can only run queries on a warehouse it has the USAGE privilege on, so give analyst roles a right-sized shared warehouse, not your largest one. (Snowflake documentation: access control privileges)

Example: Grant read-only access to analysts, and let them use only the shared reporting warehouse.

GRANT USAGE ON DATABASE mydb TO ROLE analyst_role;
GRANT USAGE ON SCHEMA mydb.public TO ROLE analyst_role;
GRANT SELECT ON ALL TABLES IN SCHEMA mydb.public TO ROLE analyst_role;
GRANT USAGE ON WAREHOUSE shared_reporting_wh TO ROLE analyst_role;

11. User Activity Monitoring

Review query history and user activity regularly to detect inefficient or unauthorized operations. Snowflake’s built-in monitoring tools can help you track usage trends. For instance, the ‘ACCOUNT_USAGE’ schema reveals usage metrics for your account, while the ‘INFORMATION_SCHEMA’ schema shows detailed information about user activity. Thus, you can track when resources were accessed and by whom.

Example: Find long-running or frequent queries that you can optimize or refactor by tracking activity with Snowflake’s metadata tables.

SELECT user_name, query_text, start_time, execution_time
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE start_time > DATEADD(DAY, -7, CURRENT_TIMESTAMP())
ORDER BY execution_time DESC
LIMIT 20;

Pair the history with alerts. A resource monitor can notify you or suspend a warehouse when it reaches a credit limit, but it covers warehouses only. For serverless features and AI services, use a budget instead. (Snowflake documentation: resource monitors)

Implementing Data Compression and Partitioning

Effective data organization lowers storage and enhances Snowflake query optimization. This section explains how Snowflake’s built-in compression and micro-partitioning optimize both storage and performance.

12. Data Compression

Snowflake automatically compresses data loaded onto its platform, and storage is billed on the compressed size. This reduces the physical storage space needed for large datasets, lowering costs while maintaining accessibility. Example: No action is needed for compression itself, and you do not need to shrink VARCHAR lengths to save storage, because a VARCHAR column consumes storage only for the data actually stored. Choosing accurate data types is still good practice:

CREATE TABLE products
  (product_id INT,
   name STRING,
   price NUMBER(10,2),  -- Use fixed precision for currency
   created_at TIMESTAMP_NTZ);

(Snowflake documentation: string and binary data types)

13. Micro-Partitioning and Clustering

Snowflake automatically micro-partitions data to optimize storage and query performance. While this happens behind the scenes, you can further improve query efficiency by defining clustering keys. Clustering helps Snowflake organize micro-partitions more intelligently, making it faster to scan relevant data and skip over irrelevant blocks, especially for large, frequently queried tables.

Example: Add clustering to a large table.

ALTER TABLE sales_data
  CLUSTER BY (customer_id, transaction_date);

Clustering has a running cost. Snowflake reclusters the table automatically as data changes, and that work is billed. Since September 1, 2026, newly clustered tables use Optima Clustering, which is billed on the volume of uncompressed data you ingest rather than on compute hours. Append-only loads clustered by ingestion time usually cost little, while updates that change clustering key values cost the most. Tables clustered before that date stay on Clustering Classic, billed as serverless compute. 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;

(Snowflake documentation: Automatic Clustering)

14. Materialized Views

Materialized views store the results of a query physically, rather than computing them on the fly. This approach improves performance for repeated queries on large datasets and reduces compute costs by avoiding redundant recalculations. Use a materialized view for expensive aggregations or filters over one large, infrequently changing table. A materialized view can query only a single table, so it cannot replace a join. Keep in mind that materialized views require Enterprise Edition and incur storage and maintenance costs, so evaluate their usage regularly.

Example: Create a materialized view for recurring aggregate queries.

CREATE MATERIALIZED VIEW daily_sales_summary AS
SELECT store_id, DATE(order_date) AS sale_day, SUM(total_amount) AS daily_total
FROM sales_data
GROUP BY store_id, DATE(order_date);

Snowflake keeps the view up to date automatically as the base data changes. However, if your data changes frequently, consider whether the performance gains justify the extra cost of maintaining the materialized view.

Query Acceleration

Query acceleration techniques reduce execution time and improve overall system efficiency. In Snowflake, this can include using pruning, warehouse scaling and the Query Acceleration Service to enhance query speed without unnecessarily increasing compute costs.

15. Pruning with Filtering

Snowflake prunes partitions automatically when queries include filters on columns that align with micro-partitions. Ensure WHERE clauses target filterable columns.

Example: Query that benefits from pruning

SELECT customer_id, total_amount
FROM sales_data
WHERE transaction_date >= CURRENT_DATE - INTERVAL '7 days';

16. Scale Out Concurrency with Multi-Cluster Warehouses

For high-concurrency workloads, Snowflake’s multi-cluster warehouses automatically start additional clusters to handle spikes, then shut them down when no longer needed. Multi-cluster warehouses require Enterprise Edition.

Example: Create a multi-cluster warehouse

CREATE WAREHOUSE analytics_wh
  WAREHOUSE_SIZE = 'LARGE'
  MAX_CLUSTER_COUNT = 3
  AUTO_SUSPEND = 300
  AUTO_RESUME = TRUE
  SCALING_POLICY = 'STANDARD';

17. Check the Query Acceleration Service

The Query Acceleration Service (QAS) lends a warehouse extra shared compute for outlier queries, such as large scans with selective filters and big inserts, updates and deletes, so you do not have to size the whole warehouse up for them. It requires Enterprise Edition. It is billed separately, by the second, only when it is used, and the QUERY_ACCELERATION_MAX_SCALE_FACTOR setting caps how much it can lease. It is switched on by default for new Gen2 and multi-cluster warehouses, so you may be paying for it without having chosen it. Review what it costs, and turn it off where it does not earn its keep. (Snowflake documentation: Query Acceleration Service)

-- 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;

These techniques, used in combination, can significantly reduce both query latency and compute cost.

Is your Snowflake spend really optimized?

See the exact warehouses, queries, and pipelines driving your costs - based on real usage.

Get a Snowflake Cost Assessment