How We Handle Snowflake Cost Optimization: Insights From Real Client Projects

Quick Summary

Introduction

Running your data workloads and daily operations on Snowflake is easy. Controlling what it costs is the hard part, and often teams struggle to rightly manage their expenses on the platform.

There can be many reasons for this, like a warehouse that was sized up to clear a slow query and never brought back down, auto-suspend left on its default setting, or a serverless feature that was switched on for a project months ago and is still running quietly in the background. All of this gets billed every second, whether the teams are aware of it or not.

We have come across many clients across the healthcare, finance, banking, and insurance industries who either are not able to control the rising costs or are not able to gain visibility into where the costs are coming from.

Read further as we cover the key challenges we faced across these engagements, the solutions we implemented, and the best practices we recommend to avoid these costs from coming back.

But first, read about how Snowflake’s pricing model works, since effective Snowflake cost optimization starts with understanding exactly how the platform charges you.

Understanding the Snowflake Pricing Model

Snowflake runs on a consumption model, so your bill is the total of what each part of the platform uses, and not an upfront licensing fee. Here are the four key components of Snowflake’s pricing structure:

Compute usually accounts for more than 80% of a Snowflake bill, which is why most of the Snowflake cost challenges come from there. Storage and serverless cost less but are easy to overlook, and your edition sets what you pay per credit for the rest.

Top 5 Snowflake Cost Challenges and How We Solve Them

These are the five Snowflake cost problems we find most often across client accounts. For each of these challenges, we have also shared some instances from actual engagements, along with the solutions we implemented.

Challenge 1: Paying for Warehouse Capacity Rarely Used

The most common mistake we find teams making is sizing up a warehouse for work bigger than the usual need. It usually starts with one slow query. Someone sizes up the warehouse, the query speeds up, and the bigger warehouse stays, even though every size up doubles the per-second cost. The size helps fix the symptom once, and then it keeps billing for it every month after.

We saw this with a fintech client whose analytics ran on a large warehouse. It had been sized that way just for some month-end reconciliation jobs that genuinely needed the headroom, but those jobs only ran a few days a month. When we pulled QUERY_HISTORY and compared queue time against execution time, about 75% of their queries were not queuing at all. For most of the month, the warehouse was paying for capacity the workload never touched, and the extra size added cost without adding any speed.

The Solution: Right-Sizing the Warehouse and Separating Heavy Jobs into a Different Warehouse

A warehouse should be sized for the workload it runs most of the time, not for the occasional heavy job. When a job like month-end reconciliation needs more compute, it can run on its own larger warehouse for those few days, while the main warehouse stays small. Since Snowflake can resize warehouses on demand, running a large one all month for work that happens on a few days adds cost without adding value.

Our Data warehouse services team reduced the client’s analytics warehouse to Medium for everyday work and moved the month-end reconciliation to a separate Large warehouse that ran only during those jobs. The reconciliation kept the compute it needed, and because the main warehouse was smaller for the rest of the month, their overall compute cost came down.

Challenge 2: Paying for Idle Warehouse Time

Snowflake charges for a warehouse by the second the whole time it is running, even when no query is using it. That is where idle spend comes from. The auto-suspend setting decides how quickly a warehouse pauses after its last query, but teams often push that timer up or switch it off to stop a dashboard warehouse from pausing between requests. The warehouse then runs and bills all day, even though the queries hitting it account for a small part of that time.

We see this often. Like, with a healthcare client, a warehouse powered a dashboard that hospital administrators checked through the day for patient volumes and bed occupancy. To keep it responsive, the warehouse was left running through business hours, and when we checked WAREHOUSE_METERING_HISTORY against actual query times, a large share of the billed hours had no queries running at all. On an insurance engagement, a warehouse feeding overnight claims and underwriting reports was left on through the night, even though the data refreshed only a few times, so it sat idle between refreshes while continuing to bill.

The Solution: Match Auto-Suspend to How Often the Warehouse Is Queried

We recommend our clients tune auto-suspend to how often the workload actually runs, rather than leaving it on the default. The one caution is the 60-second minimum: set it too tight on a warehouse that resumes constantly, and the resume charges outrun the idle time you cut.

We set auto-suspend on the healthcare dashboard to a short interval matched to its refresh rate and kept auto-resume on, so it paused between checks but loaded instantly on open. We did the same on the insurance reports around their refresh schedule. The idle hours came off both bills.

Challenge 3: Running More Clusters Than the Load Needed

Multi-cluster warehouses in Snowflake are a useful feature and one of the easiest ways to run up compute without noticing. Under concurrent load, Snowflake adds clusters so queries do not queue, then drops them when the load falls. The cost problem starts when the minimum cluster count is set above one, so the extra clusters run all the time, or when the scaling policy is eager enough to add clusters for load a single one could have handled.

A US banking client came to us with a BI bill that spiked through business hours, and no one could explain why. When we checked, it came out that their reporting warehouse was set to a minimum of two clusters at all times with the standard scaling policy, so they were always running two clusters, even during stretches when one could have kept up.

The Solution: Set the Minimum to One Cluster and Scale on Demand

We recommend our clients to start the warehouse at a single cluster and let Snowflake add more only when concurrency demands it, with the maximum set to the real peak in the data and the scaling policy chosen to fit the load.

For this client, we dropped the minimum to one cluster, set the maximum to the concurrency peak we saw in WAREHOUSE_LOAD_HISTORY, and moved the scaling policy to the economy setting, which fills a running cluster more fully before starting another. Dashboards stayed responsive when load was genuinely high, and the standing charge for a second cluster that ran mostly idle came off the bill.

Challenge 4: Queries Scanning More Data Than They Needed

Sometimes the cost is not the warehouse; it is what the queries make it do. Compute climbs when queries read far more data than the answer needs, and this happens when clustering does not match how the tables are filtered or when large joins produce oversized intermediate results.

We saw this with a finance client whose compute kept climbing while the number of queries held steady. The Query Profile in Snowsight highlighted that the largest joins were writing intermediate results to remote storage because they did not fit in memory, and the biggest tables had no clustering on the columns the queries filtered on, so Snowflake read most of each table to answer questions that needed a small part of it.

The Solution: Cluster on Filter Columns and Rework the Heavy Joins

Our usual recommendation in such cases is for better Snowflake cost management is to define clustering keys on their large tables using the columns the queries filter on, so Snowflake can skip the data a query does not need, and rework any joins that write to remote storage so the work stays in memory.

We did the same for this finance client, defining clustering keys on the high-traffic tables using those filter columns, reworked the largest joins so their intermediate results fit in memory, and set the queries to prune on the relevant partition columns. The warehouse then answered the same queries while reading much less data, and the compute cost stopped climbing.

Challenge 5: Storage Growing Faster Than the Data Behind It

Storage is cheap per terabyte, so most teams stop watching it. What runs the bill up is rarely the live data. It is Time Travel and Fail-safe holding onto historical versions of every table long after anyone needs them, plus old clones and staging tables that were never dropped. On a table that takes heavy updates, that retained history can end up larger than the table itself, and TABLE_STORAGE_METRICS will show it.

The Solution: Set Retention on Purpose and Clear Orphaned Assets

Most of this comes from leaving Time Travel on the account default across every table. We set retention per table to match how critical it actually is, keep short-lived ETL data in transient tables so it skips Fail-safe entirely, and clear out the stale clones and staging tables. For steady, predictable data, pre-purchased storage lowers the per-terabyte rate as well. The storage line then comes back in step with the data.

6 Best Practices We Recommend for Snowflake Cost Optimization

The five fixes above each solve a specific problem. These Snowflake cost optimization best practices help keep those problems from coming back, and they work at the level of people, process, and pricing rather than individual warehouses, queries, or tables.

Track Where Your Credits Go

Teams cannot cut spend they cannot see, and the most common gap we find is that a client cannot say which team is running up their credits. Tag warehouses and workloads by team and purpose, add query tags to trace cost to individual jobs, and base your reporting on the ORGANIZATION_USAGE views and the Snowsight Cost Management dashboards. Every credit needs an owner before any of the other practices can do much.

Give the Bill an Owner

After every Snowflake cost management project, the costs can rise again. As the warehouses get resized, new pipelines go live, and serverless features get switched on. The teams that keep spend flat assign one person to own the number and review it on a set schedule. A short weekly check of the cost dashboard can help catch the drift while it is still small.

Audit Serverless Features Regularly

Serverless features are the spend teams most often forget they enabled. Automatic clustering, search optimization, materialized views, and Snowpipe do not auto-suspend, so they keep billing until someone turns them off, and on high-churn tables they run at a 2x credit multiplier that can cost more than the queries they speed up. Resource monitors do not track serverless, so these features need their own place on the Snowflake cost optimization project, checked against current need.

Check Your Edition and Commitment

Teams tune their warehouses and miss the larger pricing lever. Review whether your edition matches the governance you actually use, and whether your usage has grown enough that pre-purchased capacity costs less per credit than on-demand. Committing lowers the rate on steady spend, but it can cost more on volatile spend, so the decision needs real usage data behind it.

Set Guardrails Before the Spend Runs

Resource monitors, budgets, and statement timeouts take minutes to set and prevent the warehouse being left running for days and the query that loops because nothing stops it. Put resource monitors on warehouses and Budgets on serverless, set a sensible STATEMENT_TIMEOUT_IN_SECONDS on every warehouse, and make alert and suspend thresholds standard on anything new.

Cost the Workload Before You Build It

A workload sized right the first time never needs fixing later. When a new pipeline or data product is being planned, estimate its warehouse size, run frequency, and storage against your current usage, and fold that into the design review. Sizing a workload in advance while planning, takes far less work than unwinding it after months in production.

Conclusion

Frequently Asked Questions (FAQs)

What tools do you use for Snowflake cost optimization?

We work primarily inside Snowflake’s own telemetry, because that is where the ground truth lives: the ACCOUNT_USAGE and ORGANIZATION_USAGE views, WAREHOUSE_METERING_HISTORY and WAREHOUSE_LOAD_HISTORY for compute, TABLE_STORAGE_METRICS for storage, the Query Profile for individual queries, plus resource monitors and the Snowsight Cost Management dashboards for control and reporting.

How much can Snowflake cost optimization actually save?

It depends entirely on how far the current setup has drifted from your planned budget, and the honest answer is that we have seen anything from modest single-digit trims on an already-tuned account to cutting a badly configured bill by a large fraction. The biggest Snowflake cost optimization wins almost always come from compute, since it is typically over 80% of the bill: right-sizing warehouses, killing idle time, and fixing multi-cluster settings usually move the number more than anything on the storage side.

What is the most common cause of a high Snowflake bill?

Idle and oversized compute, by a wide margin. Warehouses left running while nothing queries them, and warehouses sized for a rare peak but run at that size all month, are the two things we find on almost every bloated bill. Both are quick to fix once you can see them, which is why cost attribution comes first.

Is Snowflake cost optimization a one-time project or ongoing?

Ongoing, though it starts with a project. A one-time Snowflake cost optimization work gets you a lower baseline, but without an owner and a review rhythm, spend drifts back up as new workloads and habits accumulate. The clients who want to stay in control of their Snowflake costs should treat it as an ongoing practice and not just a project to undertake when the losses have already occurred.