The Snowflake Costs That Aren't Warehouses: Finding Hidden Serverless Spend

You can right-size every warehouse, tune every AUTO_SUSPEND, and optimize every query — and still find a stubborn slice of your Snowflake bill you can't explain. That's because not all Snowflake compute runs on a warehouse you control. A growing share runs on serverless features that Snowflake spins up automatically, bills by the second, and never shows you a warehouse for. There's nothing to suspend, nothing to resize, and nothing in your warehouse dashboards that accounts for it.

This is Leak #4 in our breakdown of why your Snowflake bill is so high: cost that hides because every optimization tool you've been using looks at warehouses, and this isn't a warehouse. Snowpipe, automatic clustering, materialized view maintenance, search optimization, replication, and serverless tasks all consume credits on their own meters. On a mature account this can be 10–30% of the bill, and almost nobody audits it.

This post shows you how to surface every non-warehouse credit, drill into the biggest offenders, and bring them back under control — all from SNOWFLAKE.ACCOUNT_USAGE.

Why serverless costs hide

Every cost lever in this series so far has a warehouse at the center of it. Right-sizing changes a warehouse's size. Auto-suspend changes how long a warehouse runs. Query attribution tells you which queries ran on a warehouse. The mental model is "warehouse = compute = cost," and for most of your bill that's true.

Serverless features break the model. When you set up Snowpipe to auto-ingest files, Snowflake runs that ingestion on its own managed compute and bills you for it — no warehouse appears. Same for automatic clustering quietly reorganizing a table in the background, a materialized view refreshing itself when its base table changes, search optimization building and maintaining its access paths, replication shipping data to another region, and serverless tasks running on Snowflake-managed compute instead of a warehouse you named. Each is useful. Each is also a meter running where nobody's looking.

The good news: they all report to one place, and one query brings them into the light.

Step 1: See every non-warehouse credit at once

METERING_DAILY_HISTORY records daily credit usage broken down by service_type. Filter out the warehouse service types and what remains is your entire serverless footprint, ranked. This query doesn't depend on memorizing exact service names — it simply shows you whatever Snowflake is billing that isn't a warehouse.

SELECT
  service_type,
  ROUND(SUM(credits_used), 2)            AS credits_30d,
  ROUND(SUM(credits_used_compute), 2)    AS compute_credits,
  ROUND(SUM(credits_used_cloud_services), 2) AS cloud_services_credits
FROM snowflake.account_usage.metering_daily_history
WHERE usage_date >= DATEADD('day', -30, CURRENT_DATE())
  AND service_type NOT IN ('WAREHOUSE_METERING', 'WAREHOUSE_METERING_READER')
GROUP BY 1
ORDER BY credits_30d DESC;

The result is usually a short list with one or two surprisingly large rows. AUTO_CLUSTERING and PIPE (Snowpipe) are the most common chart-toppers, with MATERIALIZED_VIEW, SEARCH_OPTIMIZATION, REPLICATION, and SERVERLESS_TASK filling out the rest. Whatever sits at the top is where you drill next. Multiply by your effective credit rate and you have the dollar figure that's been hiding outside every warehouse report you've run.

It's worth running this breakdown as a trend, not just a snapshot. Serverless costs creep — a new pipe here, clustering switched on for a table there, an extra replication target — and because none of it surfaces in warehouse dashboards, the creep is silent. Group the same query by month instead of summing the whole window, and you'll see which service types are growing. A service that doubled quarter over quarter is a clearer call to action than one that's simply large and steady, and catching it early is the difference between a quick tune and a painful one.

Step 2: Drill into automatic clustering — the usual #1

Automatic clustering is the most common serverless surprise, because its cost is invisible until you look and it scales with how much a clustered table changes. A table with a clustering key that gets frequent inserts, updates, or deletes will recluster continuously, burning credits around the clock. This query ranks clustering cost by table so you can see exactly which one is doing it.

SELECT
  database_name,
  schema_name,
  table_name,
  ROUND(SUM(credits_used), 2)        AS clustering_credits_30d,
  SUM(num_rows_reclustered)          AS rows_reclustered,
  ROUND(SUM(num_bytes_reclustered) / POWER(1024, 3), 1) AS gb_reclustered
FROM snowflake.account_usage.automatic_clustering_history
WHERE start_time >= DATEADD('day', -30, CURRENT_DATE())
GROUP BY 1, 2, 3
ORDER BY clustering_credits_30d DESC
LIMIT 25;

If one table dominates this list, you've found real money. The fix is rarely "turn clustering off" — it's to question whether that table should be clustered at all given its churn, whether the clustering key is too granular, or whether a high-write table would be better served by a different physical design. A single over-eager clustering key can cost more than a warehouse.

A concrete pattern to watch for: a fact table clustered on a high-cardinality column — an event timestamp down to the second, say — and fed by a streaming pipeline. Every micro-batch of inserts lands rows that violate the existing clustering order, so Snowflake reclusters almost continuously to maintain it. The table looks well-designed on paper; it is clustered, after all. But the maintenance bill dwarfs any query it speeds up. Clustering on a coarser key, or not at all, often costs a fraction and serves the same queries just as well. The only way to know is to put the clustering credits next to the actual query speedup and compare them honestly — which almost nobody does until this query forces the question.

Step 3: Drill into Snowpipe — death by tiny files

Snowpipe's cost has a notorious failure mode: file size. Snowflake charges for Snowpipe partly on a per-file basis, so ingesting a flood of tiny files costs dramatically more than ingesting the same data in a few large ones. A pipeline dropping thousands of 2 KB files a minute is one of the most expensive things you can do for the least data moved. This query ranks Snowpipe cost by pipe.

SELECT
  pipe_name,
  ROUND(SUM(credits_used), 2)     AS pipe_credits_30d,
  SUM(files_inserted)             AS files_inserted,
  ROUND(SUM(bytes_inserted) / POWER(1024, 3), 1) AS gb_inserted,
  ROUND(SUM(bytes_inserted) / NULLIF(SUM(files_inserted), 0) / 1024, 1) AS avg_kb_per_file
FROM snowflake.account_usage.pipe_usage_history
WHERE start_time >= DATEADD('day', -30, CURRENT_DATE())
GROUP BY 1
ORDER BY pipe_credits_30d DESC
LIMIT 25;

The avg_kb_per_file column is the tell. If a high-cost pipe shows an average file size in the low kilobytes, you're paying the tiny-file tax. Snowflake's own guidance is to aim for files in the 100–250 MB range; batching upstream so files arrive larger and less often can cut a pipe's cost by an order of magnitude with no loss of freshness that matters.

There's a deeper version of this decision worth making explicitly: Snowpipe isn't always the right tool. Its serverless, per-file pricing is excellent for genuinely continuous, event-driven ingestion — files arriving steadily that you need queryable within minutes. But if your data actually lands in periodic batches, hourly or a few times a day, a scheduled COPY INTO on a small warehouse can be dramatically cheaper, because you pay for a short burst of warehouse time instead of per-file overhead across thousands of objects. The honest question is how fresh the data truly needs to be. Teams reach for Snowpipe by reflex because it's the "modern" choice, then quietly pay continuous-ingestion prices for data nobody looks at before the morning standup.

Don't forget materialized views and search optimization

Two more serverless features deserve a second look once clustering and Snowpipe are handled, because they fail in the same quiet way: their cost scales with how much the underlying table changes. A materialized view keeps itself in sync with its base table, so the faster that base table churns, the more the view costs to maintain — put one on a high-write table and you can spend more keeping it current than you ever save on reads. Check MATERIALIZED_VIEW_REFRESH_HISTORY for the views burning the most credits, then ask whether each one sits on stable data or churning data.

Search optimization has the same shape. It builds and maintains a search access path, and that maintenance scales with table change. It earns its keep on large tables with frequent point-lookups on a handful of columns, and it's pure waste when switched on broadly "just in case." For both features, the question is never "is this good?" — it's "is the query speedup on this specific table worth the credits to keep it maintained?" Often it is. Just as often, nobody ever checked, and it quietly isn't.

The fix, by service

Each serverless feature has its own cause and its own remedy. Once Step 1 tells you where the money is, this table tells you what to do about it.

The overarching principle: serverless features are convenient defaults that quietly assume you want maximum freshness and maximum coverage. Most workloads don't need either. Dialing each one back to what the business actually requires is where the savings live.

Where teams get serverless costs wrong

Never looking. The single biggest mistake is assuming the bill is all warehouses. If you've never run the Step 1 query, you genuinely don't know what fraction of your spend is serverless — and you can't manage it.

Turning features off instead of tuning them. Clustering, search optimization, and materialized views exist because they make queries faster. The goal isn't to kill them; it's to apply them only where the query speedup is worth the maintenance credits. Disabling a feature that was saving you warehouse compute can cost more than it saves.

Ignoring file sizing upstream. The Snowpipe tiny-file tax is an architecture problem that lives in the system feeding Snowflake. Fixing it means changing how files are batched before they arrive, which is easy to overlook because it's not in Snowflake at all.

Assuming serverless always means cheap. Serverless features are sold as convenient and efficient, and often they are — but "serverless" is not a synonym for "cheap." A serverless task firing every minute, or search optimization on a churning table, can quietly outspend the small warehouse you were trying to avoid provisioning in the first place. Convenience has a price; the meters in this post are how you check whether you're overpaying for it.

Forgetting these compound with warehouse fixes. Serverless optimization isn't a replacement for right-sizing, auto-suspend, and query attribution — it's the fourth leak that, once sealed, means you've covered the whole bill instead of just the warehouse portion of it.

Bottom line

A meaningful slice of your Snowflake bill runs on serverless features with no warehouse to optimize — and because every standard cost tool looks at warehouses, that slice hides. Run the METERING_DAILY_HISTORY breakdown to see all of it at once, drill into automatic clustering and Snowpipe (the usual top two), and tune each feature to what the business actually needs rather than its maximum-freshness default. It's often the last 10–30% of the bill nobody else is looking at.

With this, you've now sealed all four leaks — oversized warehouses, idle time, expensive queries, and hidden serverless spend. Want them all found and quantified for your account in one pass? That's exactly what a free Snowflake cost assessment delivers: a complete, dollarized map of where your credits go and what to do about it.

This is part of our Snowflake cost-optimization series. Start with the pillar: Why Is Your Snowflake Bill So High? The 4 Biggest Leaks, and read the companion pieces on warehouse right-sizing, idle warehouses, and cost per query, or explore our Snowflake cost optimization services.*