Snowflake Cost Optimisation: 7 Fixes That Actually Work

Your Snowflake bill doubled and your query volume didn't. If that sentence made you wince, you're in good company — and the fix is rarely "negotiate a better contract."

Snowflake cost optimisation is now a board-level topic because the consumption model rewards convenience and punishes inattention. The platform will happily let a data analyst spin an X-Large warehouse for a query that needed an X-Small, and nobody notices until finance does. In our work across logistics, retail and financial services clients, we consistently find 30–50% of Snowflake spend is recoverable without degrading a single SLA. Here's how.

The Problem: Consumption Pricing Meets Nobody's Job

Snowflake's per-second compute billing is elegant, but it creates a diffuse accountability gap. Engineering owns the pipelines, analytics owns the queries, finance owns the bill — and nobody owns the credits.

The failure modes are remarkably consistent:

Oversized warehouses running undersized workloads. Teams size warehouses for their worst query, then run everything on them. A Large warehouse (8 credits/hour) executing queries that finish identically fast on a Small (2 credits/hour) is a 4x overspend, invisible in any dashboard that only tracks query duration.

Idle burn. Default auto-suspend is 10 minutes. A warehouse that receives one query every 9 minutes never suspends. We've seen warehouses billing 24/7 to serve 40 minutes of actual compute per day.

Zombie pipelines. Scheduled dbt jobs and ingestion tasks that feed tables nobody has queried in six months. The pipeline works perfectly; the output is worthless.

Full-table scans dressed up as incremental loads. A MERGE without clustering-aligned predicates rescans the target table every run. At 500GB, that's fine. At 15TB, it's the single biggest line on your bill.

Why it matters: unlike a fixed-capacity platform, waste here compounds monthly. Every new team inherits the same defaults and adds their own layer. Left alone, Snowflake spend grows faster than data volume — we typically see 60–80% year-on-year bill growth against 20–30% data growth.

The Solution: Instrument First, Then Cut

Resist the urge to downsize warehouses on day one. The sequence matters.

1. Build the attribution layer (week 1). Query SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY and QUERY_HISTORY and join credits to teams, tools and pipelines via warehouse naming conventions and query tags. If your warehouses are named WH_1 through WH_7, fix that first — TRANSFORM_DBT_PROD, BI_LOOKER, ADHOC_ANALYTICS makes every subsequent decision legible. Until you can answer "which team spent what last week," every optimisation is a guess.

2. Kill idle burn (week 1, same day you find it). Set auto-suspend to 60 seconds for transformation and ad-hoc warehouses. BI-serving warehouses with steady traffic can stay at 5 minutes to preserve the local warehouse cache — this is the one place where aggressive suspension backfires, because cold caches push query times up and users notice. Snowflake's own warehouse considerations documentation covers the cache trade-off well.

3. Right-size empirically, not theoretically. For each warehouse, compare P50 and P95 query duration before and after dropping one size. If P95 holds, drop another. Most transformation workloads are I/O-bound in ways that don't scale linearly with warehouse size — a query that runs in 90 seconds on a Medium often runs in 110 on a Small at half the credits. That 22% latency increase on an overnight batch job costs nothing; the 50% credit saving is real money.

4. Fix the top 10 queries. Sort QUERY_HISTORY by total credits consumed, not duration. The usual suspects: MERGEs missing partition-pruning predicates, SELECT * into BI extracts, and CTEs materialising the same 2TB scan four times. Adding a date-range predicate to one incremental MERGE has, in our experience, cut a client's single largest pipeline cost by 70%.

5. Put guardrails in before the next quarter. Resource monitors with notify-then-suspend thresholds per warehouse, statement timeouts (STATEMENT_TIMEOUT_IN_SECONDS) on ad-hoc warehouses, and a weekly credits-by-team report posted somewhere public. Visibility changes behaviour faster than policy does.

6. Audit the zombie estate quarterly. Join ACCESS_HISTORY against your pipeline schedules. Any table written daily but not read in 90 days is a candidate for pausing — with a two-week notice period, because someone always owns the exception.

7. Revisit storage last. Storage is usually under 10% of the bill, but check TIME_TRAVEL retention on large, high-churn tables — 90-day retention on a table rewritten nightly triples its storage footprint for no recovery benefit.

This is the same instrument-before-acting discipline we apply in our data platform assessment approach, and it's why cost work usually surfaces data quality issues too.

Real-World Example: 43% Off a Logistics Client's Bill in Six Weeks

A mid-market logistics company came to us with Snowflake spend at £34,000/month and growing ~8% monthly. Data volume: about 40TB. No warehouse naming convention, no query tagging, auto-suspend at the 10-minute default across all nine warehouses.

Week one, attribution showed 31% of credits went to a single "reporting" warehouse that was never suspending — it served a Looker instance polling on a schedule. Dropping auto-suspend to 5 minutes and moving the polling jobs to a dedicated X-Small saved £6,800/month on its own.

Weeks two to four, we right-sized six warehouses down one or two sizes (P95 query times moved by under 15% — nobody noticed) and rewrote the three most expensive MERGE statements to prune on event date. The largest pipeline dropped from 210 credits/day to 55.

Weeks five and six, we decommissioned four zombie pipelines feeding an abandoned dashboard suite and put resource monitors on every warehouse.

Result: £34,000/month to £19,400/month — a 43% reduction — with zero SLA degradation and one genuinely improved dashboard load time (warm cache on the resized BI warehouse). The monitoring layer meant spend stayed flat for the following two quarters despite two new teams onboarding. The full breakdown is in our logistics data platform case study.

Actionable Takeaways

• Attribute before you optimise. Warehouse naming conventions plus query tags turn ACCOUNT_USAGE views into a cost ledger. You can't cut what you can't see.
• Auto-suspend at 60 seconds is the highest-ROI change in Snowflake — except on cache-sensitive BI warehouses, where 5 minutes is the right trade.
• Right-size with data, not instinct: drop one warehouse size, watch P95 for a week, repeat. Batch workloads tolerate far more latency than anyone assumes.
• Sort queries by credits consumed, not runtime. Your most expensive query is rarely your slowest one.
• Guardrails beat heroics. Resource monitors, statement timeouts and a public weekly spend report keep the bill flat after you've cut it — otherwise you're doing this again next year.

If your warehouse strategy predates your current data volume, it's also worth reading our guide to modernising your data platform architecture.