The Snowflake Cost Optimization Framework

Most Snowflake cost advice is a list of knobs. This framework is different in one way that matters: every principle maps to a mechanism that enforces it, not just a recommendation to follow. A best practice you have to remember to apply decays the moment a new BI tool, a new hire, or a deadline shows up. A best practice enforced in the query path holds.

The short version. Snowflake cost optimization has a natural order of operations: suspend idle compute → right-size what runs → eliminate repeated work → make each query cheaper. Do them in that order, because each step shrinks the surface the next one has to optimize.

This is the chukei view of the Snowflake cost optimization problem, organized so a platform or FinOps team can assess where they are and what to fix next.

The optimization hierarchy

Apply these in order — earlier steps are cheaper, safer, and shrink the work left for later steps.

  ┌─────────────────────────────────┐
  │ 1. SUSPEND                      │  <- biggest, safest win
  │ stop paying for idle warehouses │
  └────────────────┬────────────────┘
                   v
  ┌─────────────────────────────────┐
  │ 2. SIZE                         │
  │ right-size what actually runs   │
  └────────────────┬────────────────┘
                   v
  ┌─────────────────────────────────┐
  │ 3. CACHE                        │
  │ skip deterministic re-runs      │
  └────────────────┬────────────────┘
                   v
  ┌─────────────────────────────────┐
  │ 4. REWRITE                      │  <- smallest, most effort
  │ make remaining queries cheaper  │
  └─────────────────────────────────┘

Step	Why it's in this order	chukei mechanism
Suspend	Idle compute is pure waste; suspending changes no results and risks nothing	suspend plugin (suggest or enforce)
Size	A right-sized warehouse multiplies every later saving	warehouse sizing / bandit
Cache	Eliminating a query beats optimizing it	verified cache + coalescing
Rewrite	Highest effort, smallest per-query win — do it last	deterministic rewrite rules

The five pillars

The hierarchy is what to do. The pillars are how to run it as a practice — each links to a deep-dive with a checklist and a copy-paste SQL recipe.

  1. Visibility   see the spend        ┐
  2. Attribution  own the spend        │  each pillar feeds
  3. Elimination  remove the waste     │  the next; the loop
  4. Efficiency   right-size the rest  │  repeats continuously
  5. Governance   keep it optimized    │
  ^────────── continuous loop ─────────┘

1. Visibility — you cannot reduce what you cannot see. Measure spend per query, warehouse, and workload.
2. Attribution — tie every credit to a team, tool, user, or dbt model so cost has an owner.
3. Elimination — remove work entirely: suspend idle warehouses, cache deterministic reads, kill duplicate runs.
4. Efficiency — right-size warehouses and make the queries that remain cheaper.
5. Governance — guardrails, budgets, and signed evidence that keep the gains from eroding.

How mature is your practice?

The maturity model scores you from ad-hoc to optimized across the five pillars. Most teams are strong on visibility and weak on attribution and governance — which is exactly the order in which spend silently grows.

Frequently asked questions

Is this the same as Snowflake's Well-Architected Framework? No. Snowflake's framework is vendor guidance you apply manually. This framework pairs each best practice with an enforcing mechanism in the query path, so the practice survives contact with real teams and tools.

Where should a team start? Visibility first (you need a baseline), then the elimination step of the hierarchy — suspend and cache are the largest, lowest-risk wins. Run the replay simulator to size the opportunity before changing any traffic.

Does applying this require changing queries or tools? No. The mechanisms operate at the wire-protocol proxy layer, so BI tools, dbt, and notebooks are covered without client changes.

---

Start with a baseline. Run the replay simulator on your QUERY_HISTORY to measure cacheable volume, idle warehouse time, and attributable spend before you change anything.