Databricks & Snowflake · Chapter 14 of 16
The cost model, from the primary documents
How credits and DBUs are actually computed, the minimums that catch people, and the six things that produce a surprise invoice on each platform.
Cost on these platforms is not a mystery; it is a published table that almost nobody reads. This chapter is the structure of that table, the mechanisms behind it, and the specific traps. Rates change, so verify before quoting — but the shape is stable and the shape is what you need.
Where to get authoritative numbers, since this is genuinely useful to know.
Snowflake publishes a Service Consumption Table as a legal document, versioned by effective date. It contains every credit rate, every serverless multiplier and every unit charge. Always cite the effective date, because it changes.
Databricks' AWS list prices are not machine-readable — the pricing page loads rates client-side. The Azure Retail Prices API is public, unauthenticated and returns exact dollars per DBU-hour, which makes it the citable source for teaching. For your own estimate, read system.billing.usage rather than trusting any published multiplier.
Snowflake: the billing minimums, and the one that changed
Everything is per-second and rounded up, after a minimum on start or resume. There are now three different minimums and the universally-taught version covers only one of them:
| What | Minimum on start or resume |
|---|---|
| A standard virtual warehouse | 1 minute — the one everybody knows |
| An interactive warehouse | 60 minutes |
| A compute node (containers) | 5 minutes |
The sixty-minute minimum is a genuine foot-gun. Interactive warehouses are cheaper per hour and are designed for sub-second high-concurrency serving — dashboards and APIs — with a minimum auto-suspend measured in hours, because they are meant never to suspend. Treat one as an ordinary warehouse, start and stop it a few times a day, and you have bought several hours you did not use.
The credit structure
- Warehouse credits double with each size: extra-small at 1 credit per hour, small at 2, medium at 4, and so on. So a size increase is only economical if the query gets more than twice as fast — which for a well-parallelised scan it often does, and for a skewed or serial query it does not.
- Newer-generation warehouses carry a multiplier — roughly 1.35× on some clouds, 1.25× on others. The break-even is exact and worth stating: at 1.35×, a next-generation warehouse only saves money if queries get more than 35% faster. That is a checkable claim per workload, not a given.
- Cloud services are free up to 10% of your daily warehouse credits, and charged beyond that. Crossing the threshold is almost always caused by very high query volume against tiny warehouses — metadata-only queries and BI tools polling the information schema.
- Serverless features carry multipliers, and this is the table worth knowing.
| Serverless feature | Compute multiplier |
|---|---|
| Classic automatic clustering | 2× |
| Materialized view maintenance | 2× |
| Search optimization service | 2× |
| Backup, copy files, data quality monitoring | 2× |
| Serverless tasks | 0.9× |
| Serverless tasks, flex | 0.5× |
| Query acceleration | 1× |
| Table optimization | 0.75× |
| Snowpipe and streaming ingest | Per gigabyte, not a multiplier |
Stack those and the arithmetic gets uncomfortable quickly: materialized view maintenance plus search optimization plus classic clustering on the same hot table is six times serverless compute running alongside your warehouses. Each was individually justified; nobody added them up.
And one footnote that is a real architecture input: file ingestion charges text files at their uncompressed size, while binary formats are charged at observed size. So gzipped JSON is billed as though you never compressed it — which is a direct argument for landing Parquet rather than compressed JSON.
Databricks: the DBU, and where Photon's cost actually comes from
You are billed in DBUs per hour, at a dollar rate that depends on the workload type and tier. Verified rates from the public cloud pricing API make one thing clear that is widely misunderstood:
| SKU | Dollars per DBU-hour |
|---|---|
| Jobs compute | 0.30 |
| Jobs compute with Photon | 0.30 — identical |
| All-purpose compute | 0.55 |
| All-purpose with Photon | 0.55 — identical |
| Serverless SQL | 0.70 |
| Interactive serverless | 0.95 |
| Automated serverless | 0.45 |
| Serverless realtime inference | 0.07 |
Photon does not cost more per DBU. It emits more DBUs.
The dollar rate is identical between Photon and non-Photon SKUs. The vendor's own wording is that Photon instance types consume DBUs at a different rate than the same instance running without it.
So the cost increase is that the same virtual machine emits more DBUs per hour, not that the DBU price rises. Third-party estimates put the multiplier around two-fold, varying by cloud — but rather than trusting any published figure, read your own system.billing.usage, which gives you the actual DBU emission for your actual SKUs.
Combine that with the fallback behaviour from the previous chapter and you have the expensive failure mode stated cleanly: a single unsupported operator puts the plan on the slower engine while the faster meter keeps running.
The other structural point: with classic compute you pay Databricks the DBU and your cloud provider for the virtual machines; with serverless you pay only Databricks, and the infrastructure is included. That is why the serverless dollar-per-DBU is meaningfully higher — it is not a premium for convenience alone, it is a different scope of what the number covers, and comparing the two rates directly is a category error.
What actually produces a surprise bill
On Snowflake, in rough order of frequency:
- Auto-suspend set too long across many warehouses — idle at full size, multiplied by cluster count.
- Auto-suspend set too short — cache dropped, everything re-scanned.
- Classic automatic clustering at a 2× multiplier on an update-heavy table.
- Serverless features stacking on the same hot table.
- Compressed text files billed at uncompressed size on ingest.
- Cloud services crossing the 10% threshold from high-volume metadata queries.
- An interactive warehouse treated as an ordinary one, hitting the 60-minute minimum repeatedly.
On Databricks:
- All-purpose compute used for scheduled jobs. At 0.55 against 0.30 that is an 83% premium for identical work, and it is the single most common finding in a cost review.
- Photon left on for short queries, where the documentation itself says it does not help below about two seconds — while the higher DBU consumption still applies.
- Photon silently falling back because of a UDF or a stateful streaming operator.
- Auto-termination unset on interactive clusters.
- Serverless chosen for convenience where a classic warehouse would do.
- Vector search or model-serving endpoints that never scale to zero.
The pattern across both lists is worth naming: almost none of these are inefficient queries. They are configuration defaults, idle resources, and features that were each individually justified. Which is why a cost review should start with the billing tables and the cluster configuration rather than with query tuning — the money is usually not where the engineering instinct looks first.
Check yourself