Cloud Data Warehouse Costs Compared: 4 Platforms, Real Math

Cloud data warehouse pricing is one of the few technology decisions where the invoice can legitimately vary by a factor of ten between two teams running what looks like identical workloads. The reason is not vendor markups. It is that the four leading platforms bill in four different units — credits, bytes scanned, compute units and node-hours — and each unit responds differently to the same engineering behavior.

This analysis breaks each model down to its billing unit, builds comparable monthly cost models for a small, mid-size and large workload, and identifies the line items that most often cause a bill to overshoot its forecast. It is written for teams budgeting a migration or preparing a renewal, not for readers looking for a feature checklist.

The four billing units, explained

Snowflake charges platform credits. A credit is consumed per second of warehouse runtime, and the rate per credit depends on edition: list pricing is $2.00 per credit on Standard and $3.00 per credit on Enterprise (Snowflake pricing). Because warehouses are sized in T-shirt sizes — XS through 6XL — a Medium warehouse consumes four credits per hour while running, an X-Large consumes sixteen. Storage is billed separately per terabyte per month. Third-party analyses put storage at roughly $23 per TB per month and note that effective per-credit rates vary by region and cloud (Keebo).

BigQuery charges either per byte processed or for dedicated compute capacity. On-demand pricing is $6.25 per TiB of data scanned in most regions, with the first 1 TiB of queries each month free; capacity pricing starts at $0.04 per slot-hour (BigQuery pricing). Storage is billed separately, and long-term storage pricing applies automatically to tables not modified for 90 days.

Databricks charges Databricks Units (DBUs), which are multiplied by the cloud virtual machine cost underneath. Published starting rates are $0.15, $0.22 and $0.40 per DBU depending on workload class and tier (Databricks pricing). Independent cost guides report all-purpose compute nearer $0.55 per DBU and jobs compute nearer $0.22 per DBU (CloudForecast). This two-part bill — DBUs plus the AWS, Azure or GCP infrastructure line — is the single most common source of forecasting error on Databricks.

Amazon Redshift charges per node-hour, or per Redshift Processing Unit for serverless. AWS publishes a worked example: four RA3 instances at $3.26 per hour across 730 hours is $9,519.20 in compute, and a total monthly cost of $10,602.24 once storage and other charges are included (Amazon Redshift pricing). Entry configurations start around $0.543 per hour, and reserved instances discount list rates substantially in exchange for one- or three-year commitments.

Worked cost models

The table below applies published list rates to three workload profiles. Figures exclude storage and data transfer, and are arithmetic illustrations rather than quotes; real invoices depend on concurrency, caching and region.

Two conclusions follow immediately, and both are routinely missed in procurement decks.

First, on-demand BigQuery is dramatically cheaper than the alternatives when queries scan small amounts of data, because columnar partitioning and clustering reduce bytes scanned rather than wall-clock time. The same 400 TiB workload becomes expensive the moment analysts run unpartitioned SELECT * queries across full tables.

Second, Snowflake’s bill is driven by warehouse runtime multiplied by size, not by data volume. A team that leaves a Medium warehouse running eight hours a day for 22 working days burns 704 credits — about $2,112 per month on Enterprise — even if it queries almost nothing. Auto-suspend settings, not query tuning, are the first lever.

Where warehouse bills actually go wrong

Idle compute. Snowflake warehouses bill while running, including the 60-second minimum and any auto-suspend delay. Reducing auto-suspend from 10 minutes to 60 seconds on a warehouse used 20 times a day reclaims roughly nine hours of runtime per week at that size.

Full-table scans. BigQuery’s on-demand model bills the bytes read. A dashboard that scans a 5 TB table hourly costs 5 TiB × 24 × 30 = 3,600 TiB per month at list rate — an obviously unsustainable pattern that partitioning plus a materialized aggregate resolves.

Under-sized clusters on Redshift. Concurrency scaling and short-query acceleration are billed as add-ons. Teams that size for average load and enable concurrency scaling for peak hours often pay more than a slightly larger reserved cluster.

VM sprawl on Databricks. Because DBUs are charged on top of cloud VMs, an autoscaling cluster with a generous maximum node count can double its effective cost within minutes of a badly written join. Spot instances and Photon-enabled runtimes change both lines of the bill.

Storage creep. All four platforms bill storage independently and generally at declining rates with age or tier. Retaining raw event data indefinitely is often the second-largest line item after compute, and it is the easiest to fix with lifecycle policies.

Adjacent costs the comparison tables omit

Serverless features inside these platforms — Snowflake’s serverless tasks and automatic clustering, BigQuery BI Engine reservations, Databricks SQL warehouses, Redshift Serverless RPU-hours — are billed on their own scales and rarely appear in vendor comparison pages. Data egress between regions or clouds is billed by the underlying provider. Reverse ETL and BI tools re-query the warehouse, so a BI tool with a “live connection” mode can multiply warehouse compute. Budget the warehouse plus 15–30 percent for these adjacent charges unless you have measured them.

Commitment structures and how to evaluate them

All four vendors sell discounted commitments, and all four make them hard to compare. Snowflake sells prepaid capacity; BigQuery sells slot commitments with one- and three-year terms; Databricks discounts commit-spend units; Redshift sells reserved nodes with all-upfront, partial-upfront and no-upfront options. AWS states that Redshift reserved instances can save a substantial share of on-demand cost in exchange for the term (Amazon Redshift pricing).

The evaluation test is not the discount percentage. It is the break-even utilization: the fraction of committed capacity you must consume before the commitment beats on-demand. Ask each vendor for that number explicitly, then compare it against your 12-month trailing utilization for the narrowest workload you would commit.

A decision framework

1. Model your scan volume, not your data volume. Total stored terabytes is irrelevant to BigQuery costs; bytes scanned per month is the only input that matters.
2. Model peak concurrency. Warehouses are sized for simultaneous users, so 40 analysts on a Monday morning drive cost more than average utilization suggests.
3. Separate storage from compute in the model. Storage is predictable; compute is behavioral. Forecast them on different curves.
4. Run a two-week instrumented pilot on your three heaviest queries and two most-used dashboards before signing anything.
5. Price the exit. Data egress, proprietary file formats and semantic-layer lock-in all carry migration costs that should be discounted against the three-year price.
6. Assign an owner. A named FinOps owner with query-log access changes cost behavior more reliably than any discount negotiation.

Common mistakes

Treating a vendor’s “starting at” price as an effective rate; comparing annual commitments against monthly on-demand totals; ignoring that Databricks bills infrastructure separately; assuming a serverless tier eliminates capacity planning (it eliminates provisioning, not cost variability); and choosing a platform on benchmark query performance when the binding constraint is usually analyst concurrency and cost governance.

Conclusion

There is no cheapest cloud data warehouse. There is a cheapest warehouse for a specific scan profile, concurrency pattern and governance maturity. BigQuery wins on sporadic analytical scans of well-partitioned data; Snowflake wins on predictable multi-team concurrency where workload isolation matters; Databricks wins when the same platform must serve engineering and machine learning; Redshift wins for steady, high-volume workloads where reserved capacity discounts can be locked in.

Model the billing unit your chosen platform actually uses, instrument it for two weeks, and only then negotiate a commitment. Teams that reverse that order tend to discover the mismatch during the first renewal.

Sources

• Snowflake pricing options
• BigQuery pricing
• Databricks product pricing
• Amazon Redshift pricing
• Keebo: Snowflake pricing analysis
• CloudForecast: Databricks pricing guide
• CloudZero: Redshift pricing guide