Snowflake

How I Cut a Snowflake Bill by 40% Without Anyone Noticing a Slowdown

Snowflake cost optimization isn't about turning things off — it's about warehouse discipline, query hygiene, and modelling. Here's the playbook that reliably works.

All posts
3 min read28 Jun 2026

Snowflake makes it gloriously easy to spend money. Spin up a warehouse, run a query, get an answer in seconds — and quietly burn credits the whole time. Left unmanaged, a Snowflake bill grows like a garden: fast, and in every direction at once.

I've walked into several platforms where the bill had roughly doubled year on year with no corresponding growth in value. Bringing it back down — often by 30–40% — almost never requires sacrificing performance. It requires discipline in a handful of specific places.

1. Right-size and split your warehouses

The single most common waste I see is one big warehouse doing everything. Ad-hoc analyst queries, scheduled transformations, and BI dashboards all share the same oversized compute, so it's sized for the worst case and idle-but-running the rest of the time.

Split workloads onto separate warehouses sized for their actual profile, and let each one auto- suspend aggressively — 60 seconds of idle is plenty. A warehouse you're not using should cost nothing. Most "we need a bigger warehouse" problems are really "we need a second warehouse" problems.

2. Stop paying for the same scan twice

Turn on and lean into the result cache. Identical queries against unchanged data should return instantly and for free. When dashboards re-run the same aggregations every few minutes, caching alone can erase a surprising slice of the bill.

Then attack the scans that do run. Well-chosen clustering on large tables means queries prune to the partitions they need instead of scanning everything. Less data scanned is less compute burned and a faster query — the rare optimisation with no trade-off.

3. Model for the query, not just the schema

A lot of Snowflake spend is really a modelling problem wearing a compute costume. If every dashboard joins six raw tables and aggregates on the fly, you're paying for that work over and over.

Pre-aggregate the expensive, common paths into curated marts. Materialise what's queried constantly. The compute you spend once at build time is compute you don't spend on every dashboard load. This is where analytics engineering pays for itself.

4. Make cost visible

You can't manage what nobody can see. I put resource monitors on warehouses to cap runaway spend, and I build a simple dashboard from Snowflake's own usage views showing cost by warehouse, by team, and by query pattern. The moment engineers can see the cost of their queries, the worst offenders quietly disappear. Visibility changes behaviour more than any policy memo.

5. Kill the zombies

Every mature platform accumulates them: hourly jobs feeding reports nobody opens, transformations for a deprecated product, a warehouse someone spun up for a POC in 2023. Audit what's actually consumed downstream and retire the rest. It's unglamorous and it's often the biggest single win.

The mindset

None of this is exotic. Snowflake cost optimization rewards discipline, not cleverness: size compute to the workload, scan less data, model for the questions you actually ask, and make spend impossible to ignore. Do that, and you cut the bill meaningfully while queries get faster — which is exactly why nobody notices anything except the finance team, who notice the good part.

#Snowflake#FinOps#Cost Optimization#Performance
Share

Get new essays in your inbox

Occasional notes on AI engineering and data architecture. No spam, ever.