The Compute Bill Doubles Before the Query Gets Faster

Consumption pricing mechanics compared: Snowflake's vertical resize model vs. Databricks' horizontal auto-scaling, sourced to both vendors' documentation and independent analysis.

What Snowflake claims

Snowflake's comparison page asserts "2x faster performance" for core analytics with "50–70% average cost savings when migrating from Databricks." The methodology footnote reads: "These are based on real-world customer POCs and third party testing, and should not be interpreted as guarantees of performance. Results may vary depending on configuration, workload, and data characteristics."[1] The linked third-party test is Squadron Data, a Snowflake consulting partner, not an independent benchmarking firm.[2]

No standardized benchmark (TPC-DS, TPC-H) is cited. The case studies behind the savings claims (Moser Consulting, IGS Energy, TravelPass, Bond Brand Loyalty, OM1) are self-selected customer testimonials—informative, but not a controlled comparison of pricing mechanics. This piece looks at the mechanics themselves.

The credit table nobody reads

Every Snowflake warehouse is assigned a T-shirt size. Each size up doubles the credit consumption per hour:[3]

The dollar column uses Snowflake's published Enterprise on-demand rate of $2.00 per credit. Business Critical customers pay $3.00.[4] A team going from Medium (4 credits/hr) to X-Large (16 credits/hr) quadruples the credit burn rate for, as Snowflake's own docs state, a workload that "approximately doubles" in computing power per step.[3] The query may run faster. The bill scales past it.

What the billing model actually charges for

Not just compute time. Every start, every resume, and every resize carries its own minimum charge. Snowflake's documentation states: "Compute-Hours are calculated on a per-second basis. Compute-Hours have a 60 second (1 minute) minimum each time the warehouse resumes."[5] The same 1-minute minimum applies each time a warehouse is resized to a larger size.

Snowflake's warehouse considerations page gives a concrete example: "If a warehouse runs for 61 seconds, shuts down, and then restarts and runs for less than 60 seconds, it is billed for 121 seconds (60 + 1 + 60)."[6] Resizing provisions additional compute resources that are "billed when they are provisioned."[6]

There is also a hidden cost to downsizing. Snowflake's docs note that reducing a warehouse size drops the cache. A team that resizes up for a spike, then resizes back down, loses the data cache and may need to resize up again when the next query hits cold storage.[6]

A worked example: the Monday morning resize

Consider a data team running a Medium warehouse (4 credits/hr, $8.00/hr at Enterprise pricing):

The team paid XL rates (16 credits/hr) for what was a 2-minute spike. The warehouse stayed at XL for every subsequent resume. If they remember to resize back to Medium, the resize itself drops the cache and triggers another billing minimum at the higher rate.[6] In practice, most teams leave the warehouse at the larger size "just in case," and the higher burn rate becomes the new baseline.

Snowflake's auto-suspend feature does stop the meter when the warehouse is idle. But the 1-minute minimum on each resume means that bursty workloads—short queries arriving in clusters—accumulate minimum charges at whatever size the warehouse was last set to.

What the alternative looks like

Databricks SQL warehouses scale horizontally: instead of resizing one warehouse to a bigger T-shirt, the system adds or removes clusters of a fixed size.

Serverless SQL Warehouses use what Databricks calls "Intelligent Workload Management" (IWM), an ML-based system that adds and removes clusters based on queue depth and query complexity. Startup time is 2–6 seconds. There is no warehouse sizing decision for the operator to make. Billing is per-DBU, per-second, with no 1-minute minimum per start.[7]

Classic and Pro SQL Warehouses use rule-based horizontal scaling within configurable min/max cluster bounds. Scale-up is triggered when queries queue for 2–6 minutes; scale-down happens after 15 minutes of low load. The limit is approximately 1 cluster per 10 concurrent queries.[7]

The architectural difference is structural: Databricks adds parallel capacity (more clusters of the same size) for concurrency spikes. Snowflake's default path is vertical—resize one warehouse to a bigger size for performance. A Databricks warehouse that scales up for a Monday morning spike scales back down automatically when the spike passes. No manual resize, no minimum-charge penalty on the scale-down, no cache dropped.

Pricing comparison: Databricks SQL Serverless is $0.70/DBU on AWS (this includes cloud infrastructure cost). Classic is $0.22/DBU and Pro is $0.55/DBU, but these rates exclude the underlying cloud instance cost, which the customer pays separately to the cloud provider. Auto-stop defaults to 10 minutes for Serverless and 45 minutes for Classic/Pro; when stopped, the charge is zero.[8][9]

Neither vendor's pricing is cheaper in every scenario. The difference is in how costs compound under bursty, variable workloads—the kind most analytics teams actually run.

Snowflake’s own alternative: multi-cluster warehouses

Snowflake does offer horizontal scaling through multi-cluster warehouses, where multiple copies of a warehouse run in parallel. In auto-scale mode, Snowflake "starts and stops clusters as needed to manage the current load."[10] Credits consumed equal credits_per_hour multiplied by the number of running clusters.

But Snowflake's own documentation draws an explicit boundary around this feature: "Multi-cluster warehouses are best utilized for scaling resources to improve concurrency for users/queries. They are not as beneficial for improving the performance of slow-running queries."[10] In other words, multi-cluster helps when many users hit the same warehouse simultaneously. It does not help when a single query is slow because the warehouse is too small. For that, the resize button is still the prescribed path, and the doubling cost curve from the credit table above still applies.

Multi-cluster warehouses also require Enterprise Edition or higher ($2.00/credit minimum), and each added cluster carries the same 1-minute billing minimum when it starts.[4][10]

What the independent analysis says

VendorBenchmark, which assessed 45+ enterprise deployments, found that at sub-100 TB data volumes, pricing between Snowflake and Databricks is marginal. At 200 TB or above, or for ML-heavy workloads, Databricks was 9–16% cheaper on a 3-year TCO basis. Their key finding: "Organizations comparing on credits-per-month alone were systematically underestimating true costs by 35–40%."[11]

Keebo.AI reached a similar conclusion from a different angle: "Neither platform is inherently more cost effective than the other." Snowflake reaches minimum efficient scale earlier for SQL-heavy analytics; Databricks economics improve with data volume and ML workloads.[12]

Both findings contradict a blanket "50–70% savings" claim. The truth depends on workload shape, data volume, and whether the team's query pattern triggers Snowflake's resize-and-compound cost dynamics or runs steadily at a single warehouse size.

We concede

Auto-suspend is genuine and well-shipped. Snowflake's auto-suspend stops the credit meter when no queries are running. For teams with long idle windows between workloads, this is real savings, and it shipped before Databricks had a comparable auto-stop feature at the same granularity.

For sustained, predictable workloads, the resize is the right call. A team running 8-hour ETL jobs that consistently need XL-class compute should resize to XL and leave it there. The cost curve is linear and predictable. The trap is for bursty, variable workloads—dashboards, ad-hoc analytics, mixed concurrency—where the resize outlives the spike that triggered it.

Snowflake's per-second billing after the minimum is precise. Once past the 1-minute floor, Snowflake charges per-second with no rounding. This is a genuine improvement over per-hour billing models and should not be understated.

The limits of this argument

This piece compares pricing mechanics, not total cost. We cite no dollar-amount savings because total cost depends on workload shape, data volume, warehouse configuration, cloud region, contract terms, and negotiated discounts that neither vendor publishes. The credit table and billing rules are public; the actual bill is not.

Databricks Serverless SQL is newer and less battle-tested at extreme scale than Snowflake's warehouse model, which has been in production since 2014. Feature maturity is a legitimate consideration that a pricing comparison alone cannot capture.

Neither vendor publishes a reproducible, standardized benchmark on the same workload. Snowflake cites POC results and case studies; Databricks cites TPC-DI results. Both are marketing documents. We encourage running your own workload on both platforms before making a cost decision.

Comparison matrix

The verdict

Snowflake's comparison page claims "50–70% savings." The claim rests on customer POCs with a footnote that says "should not be interpreted as guarantees of performance." The independent analyses that do exist (VendorBenchmark, Keebo.AI) find the answer depends on workload type and data volume, not on which vendor's marketing page you read last.

What is not debatable is the pricing mechanic: Snowflake's default scaling path doubles the credit rate at each step, carries a 1-minute minimum per resize, and drops the cache on downsize. Databricks' default scaling path adds and removes parallel capacity without changing the per-cluster rate or triggering a minimum-charge penalty. For bursty, variable workloads, these mechanics compound differently. The credit table is public. The math is straightforward. Run the numbers on your own workload.

Sources

[1] Snowflake, “Snowflake vs. Databricks.” https://www.snowflake.com/en/snowflake-vs-databricks/

[2] Squadron Data, “Snowflake Power Up, Costs Down.” https://squadrondata.com/snowflake-power-up-costs-down/

[3] Snowflake, “Warehouse overview.” https://docs.snowflake.com/en/user-guide/warehouses-overview

[4] Snowflake, “Pricing options.” https://www.snowflake.com/en/pricing-options/

[5] Snowflake, “Understanding compute cost.” https://docs.snowflake.com/en/user-guide/cost-understanding-compute

[6] Snowflake, “Warehouse considerations.” https://docs.snowflake.com/en/user-guide/warehouses-considerations

[7] Databricks, “SQL warehouse behavior.” https://docs.databricks.com/aws/en/compute/sql-warehouse/warehouse-behavior

[8] Databricks, “Create a SQL warehouse.” https://docs.databricks.com/aws/en/compute/sql-warehouse/create

[9] Databricks, “Databricks SQL pricing.” https://www.databricks.com/product/pricing/databricks-sql

[10] Snowflake, “Multi-cluster warehouses.” https://docs.snowflake.com/en/user-guide/warehouses-multicluster

[11] VendorBenchmark, “Snowflake vs Databricks TCO benchmark comparison.” https://vendorbenchmark.com/blog/snowflake-vs-databricks-tco-benchmark-comparison

[12] Keebo.AI, “Snowflake vs Databricks.” https://keebo.ai/blog/snowflake-vs-databricks/