FinOps Inform

Snowflake Cost Optimization: Five Levers Engineers Can Apply in 90 Days

Engineer runbook to cut Snowflake credits: triage idle compute and cold storage, fix the costliest queries, pilot serverless features. Includes a $36,000...

Kori August 30, 2026 · 14 min read

Triage idle compute and unused storage first, instrument continuous monitoring second, then tune queries and pilot serverless features. Start with auto-suspend and warehouse right-sizing, prune cold tables you've paid to store for months, and fix the handful of queries burning most of your credits. Serverless features like Query Acceleration Service can help, but only after you've validated them against your actual workload.

TL;DR:

Prioritize fixing idle warehouses through auto-suspend and right-sizing, especially those spending more than 50% of active time idle to cut costs efficiently.

Focus on optimizing expensive queries by reducing bytes scanned and avoiding full table scans with wide tables to prevent unnecessary credit consumption.

Regularly prune cold data and unused tables over 100 GB to slow storage cost growth and improve overall spend management.

Evaluate serverless features like Query Acceleration Service and materialised views carefully with workload-specific testing to avoid unnecessary expenses.

Implement continuous monitoring and set specific budget alerts, analyzing actual account data weekly to catch unexpected charges early.

What is Snowflake cost optimization and where do you start?

Snowflake cost optimization means systematically reducing consumed credits across compute, storage, and serverless features without breaking query performance or data freshness. It isn't a single setting you flip. It's a triage process: find where credits are leaking, fix the biggest leaks first, then build monitoring so they don't reopen.

Five levers cover almost everything that matters, and they don't carry equal weight:

Warehouse controls (auto-suspend, right-sizing, multi-cluster scaling): highest impact, lowest effort. Most teams find a significant portion of compute waste sitting here in idle time alone.
Query-level tuning: high impact, medium effort. A handful of repeated, expensive queries usually account for a disproportionate share of monthly credits.
Storage lifecycle management: medium impact, low effort. Pruning cold tables and setting sensible retention windows is mostly a one-off clean-up job.
Serverless features (QAS, Automatic Clustering, Search Optimization, materialised views): variable impact, higher effort. These need workload-specific validation before you switch them on account-wide.
Monitoring and governance: compounding impact, ongoing effort. This is what stops the other four from regressing six months later.

To decide what to tackle first, pull three numbers: warehouse idle time as a percentage of active time, credits consumed ranked by warehouse, and table last-accessed dates for anything over 50 GB. Whichever number looks worst is where you start.

How do you right-size Snowflake warehouses without breaking SLAs?

A warehouse that's active but idle more than 50% of the time it's running is a warehouse burning money for nothing. That threshold comes directly from Snowflake's own warehouse guidance, and it's the single fastest diagnostic you can run this week.

Right-sizing follows a simple discipline: start small, scale up only when query performance data tells you to. Here's the sequence we'd recommend running:

Set auto-suspend to 5 minutes or lower on every warehouse as a baseline. This is the floor Snowflake itself recommends for reducing idle compute costs.
Rank warehouses by consumed credits using Account Usage queries against WAREHOUSE_METERING_HISTORY, then cross-reference against query volume to spot warehouses doing little work for their size.
Downsize before you upsize. Move an XL warehouse to a Large, watch query latency for a week, and only reverse the change if SLAs slip.
Check multi-cluster settings for min=max configurations. Setting minimum and maximum clusters to the same number prevents scale-down entirely, which is one of the most common silent cost leaks in multi-cluster warehouse setups.
Reserve Snowpark-optimised warehouses for memory-intensive workloads only (large joins, machine learning feature engineering) rather than defaulting to them for standard SQL.

Pro Tip: Auto-resume is not optional. If a warehouse is suspended and a query hits it, resume happens automatically and adds negligible latency. Teams who leave warehouses running "just in case" are almost always paying for compute they never use.

Which queries are actually costing you money?

Query History and ACCOUNT_USAGE.QUERY_HISTORY hold everything you need: bytes scanned, execution time, warehouse used, and the query text itself. The metric that matters most isn't runtime. It's bytes scanned per query multiplied by how often that query runs. A five-second query that fires 10,000 times a day costs more than a five-minute query that runs once a week.

Sort by that combined metric and you'll usually find the same patterns repeating:

SELECT * on wide tables where only three or four columns are ever actually used downstream.
Missing predicate pushdown, where filters get applied after a full table scan instead of before it.
Joins ordered from largest to smallest table instead of the reverse, forcing Snowflake to hold more data in memory than necessary.
Repeated complex aggregations recalculated on every dashboard refresh that would be cheaper as a materialised view.
Unnecessary ORDER BY clauses in intermediate dbt models, which force a full sort on data nobody needs sorted until the final output.

If you're running dbt, add a specific check to your review process: prune models nobody queries downstream, avoid wide ephemeral models that duplicate the same scan across multiple layers, and audit your ORDER BY usage in staging models specifically. The Getting started guide from Snowflake points to exactly these Account Usage fields as the starting point for prioritising tuning work.

Fix in order of frequency times cost, not runtime alone. A query that's merely slow but runs once a month is a distraction from the one running every five minutes.

Why is your cold data still costing you every month?

Storage is the lever teams forget because it doesn't show up as a dramatic spike. It's a slow bleed. Any table over 100 GB that hasn't been queried in a year is a candidate for archiving or deletion, and most Snowflake accounts we've looked at have several.

The fix depends on the data's nature:

Archive genuinely historical data to cheaper external storage if it's needed for compliance but never queried operationally.
Delete duplicate or superseded tables left behind by old pipeline versions. These accumulate fast in teams with high dbt model churn.
Use transient tables for high-churn staging data instead of permanent tables, which avoids Fail-safe costs entirely and lets you shorten Time Travel retention to a day or less.
Set retention windows deliberately, not by default. A 90-day Time Travel window on a table that's rebuilt nightly is pure storage cost with no recovery benefit.

Snowflake's Definitive Guide to Managing Spend makes a point worth repeating: pruning cold data is often higher-leverage than minor query tweaks once it accumulates, because storage costs compound silently every month while query costs only bite when the query actually runs.

To surface candidates, query ACCOUNT_USAGE.TABLE_STORAGE_METRICS alongside last-access timestamps, sorted by table size descending. That single query usually produces an uncomfortable list within seconds.

Do serverless features like QAS actually save you money?

Query Acceleration Service, Automatic Clustering, Search Optimization, and materialised views all promise better price-for-performance, but none of them are free, and none of them help every workload. Snowflake is explicit that these features require workload-specific evaluation rather than blanket enablement.

Here's what each one actually does and when it earns its cost:

Query Acceleration Service helps large table scans with selective filters or aggregations. Enabling it on queries without that pattern adds cost with little upside, since QAS is billed per second against a configurable scale factor.
Automatic Clustering benefits tables with frequent, filtered queries on a consistent column, but it consumes background credits continuously, which the Definitive Guide flags as a maintenance cost to weigh against query savings.
Materialised views pay off on expensive, repeated aggregations, not on data that changes every few minutes.
Search Optimization suits point-lookup queries on high-cardinality columns, not analytical scans.

Pro Tip: Use SYSTEM$ESTIMATE_QUERY_ACCELERATION and Account Usage query history before enabling any of these account-wide. Pilot on one representative production workload for a week, measure the credit delta, and only then decide whether to expand.

How do you monitor Snowflake spend before it surprises you?

Snowflake's Optimization insights, built on Account Usage, flag rarely used tables, infrequently queried materialised views, and warehouses with long idle gaps. The catch is the refresh cadence: weekly. A runaway query on a Tuesday won't show up in insights until the following week, by which point you've already paid for it.

A workable governance setup looks like this:

Tag every warehouse, database, and pipeline by team or product line so spend can be attributed, not just totalled.
Set budget alerts at 70% and 90% of monthly forecast, not just at the point you've already overspent.
Assign a named owner for spike investigation. When an alert fires, that person pulls Query Profile and warehouse metering history for the affected window within the same day.
Review Optimization insights weekly as a standing task, not an ad hoc check.
Layer continuous monitoring on top of Snowflake's native tools for anomaly detection between the weekly refresh cycles, since a week's delay is a week of unnecessary spend on a genuine anomaly.

That last point is where a lot of teams get caught out. Snowflake's own Optimization insights documentation is genuinely useful, but it was never designed for real-time alerting, and treating it as your only line of defence leaves a blind spot exactly where surprise bills tend to appear. Building an internal cost dashboard that layers your own tagging and thresholds on top of Account Usage data closes that gap.

What should you actually do in the first 90 days?

Structure the work in three phases rather than trying to fix everything simultaneously.

Days 0 to 7: triage. Run the Account Usage queries to surface idle warehouses, your top 20 queries by frequency times bytes scanned, and any table over 100 GB untouched in a year.
Weeks 2 to 4: remediation sprint. Apply auto-suspend and right-sizing to every warehouse on your list, archive or delete the cold tables you found, and rewrite the worst-offending queries.
Month 2 to 3: lock it in. Enforce tagging across all new pipelines, set budget alerts, and pilot one serverless feature on a single workload before considering wider rollout.

Pro Tip: Track credits consumed week over week from day one, not just the total bill. A falling weekly trend is proof your changes are working; a flat bill despite "fixes" means you triaged the wrong warehouse.

How Koritsu found $36,000 a year hiding in a replication job

A recurring SQL replication process was quietly consuming far more compute than the business it supported justified. Nobody had flagged it because the job ran successfully every time. It just ran expensively.

Engineer holding inactive tablet near servers

Koritsu's diagnostics traced the cost back to inefficient join logic in the replication query itself, not the warehouse size or schedule. Rewriting the query logic cut the credits it consumed on every run, and the verified saving landed at $36,000 a year, confirmed against actual billing data rather than estimated.

That's the pattern behind most large Snowflake savings we find: the fix isn't a bigger warehouse or a stricter suspend setting. It's a root-cause architectural read of what a query is actually doing, paired with an engineer who can rewrite it correctly. Kori, Koritsu's AI platform, surfaces where credits are concentrating; the specialists behind it turn that signal into a shipped fix.

What I've learned watching Snowflake accounts bleed credits

The three traps I see most often aren't exotic. Cold data piles up because nobody owns deletion decisions. Multi-cluster warehouses get set with minimum equal to maximum, which quietly kills the entire point of scaling. Serverless features get switched on account-wide because a blog post recommended them, not because anyone checked whether the workload actually matches the pattern that benefits.

Three rules of thumb hold up consistently: measure before you change anything, start with the smallest safe adjustment rather than the boldest one, and instrument continuously rather than checking in once a quarter. If your team has already run the obvious fixes and the bill still doesn't move, that's usually the point where an outside diagnostic earns its cost. Not because your engineers can't do the work. Because a fresh set of eyes on Account Usage data catches patterns internal teams stop seeing after months of familiarity.

Get a free Snowflake spend assessment

Koritsu AI is the alternative to guessing your way through Account Usage dashboards: our AI agent Kori continuously analyses your Snowflake and cloud spend, flags exactly where architecture is causing waste, and our FinOps specialists implement the fix alongside your engineers.

You start with a free assessment, and Koritsu only takes a share of the savings we actually verify against your billing, the same model that surfaced the $36,000 replication saving above. There's no upfront retainer and no commitment to continue. Teams that want ongoing coverage can move onto a subscription for continuous monitoring and anomaly detection between Snowflake's weekly Optimization insight refreshes, which closes the gap we described earlier. If you're weighing Snowflake against other platforms entirely, this comparison of Databricks and Snowflake is worth a read before committing further spend either way. To find out what's hiding in your own account, start with Koritsu's free assessment.