A cloud data warehouse pricing comparison is a structured cost analysis that breaks down compute, storage, and data transfer charges across platforms such as Snowflake, BigQuery, and Redshift to help teams select the right deployment model for their workload and budget. The three platforms use fundamentally different billing primitives, which means a single headline rate hides more than it reveals. A finance lead who compares "dollars per hour" alone will misprice the workload by an order of magnitude once idle-time behavior, query bytes processed, and managed storage rates enter the picture.
Snowflake bills compute in credits consumed by virtual warehouses; BigQuery either charges per tebibyte of query bytes processed or per slot-hour under capacity pricing slots; Redshift offers a provisioned cluster billed by the hour or a serverless compute model billed per second with no idle charges. Each primitive carries its own optimization levers, its own failure modes, and its own surprise line items on the monthly invoice.
How Cloud Data Warehouse Pricing Works
Cloud data warehouse (CDW) pricing decomposes into three universal dimensions across every major vendor: compute, managed storage, and data transfer charges. Each platform expresses these dimensions in a different unit of measure, which is why a flat side-by-side rate sheet rarely answers the buying question. The compute pricing model is the most variable axis: one vendor sells credits, another sells bytes processed, the third sells hours of cluster uptime.
- Compute
- The metered work of executing queries, loading data, and running DML. Billed in credits, in tebibytes scanned, or in hourly cluster rates depending on the platform.
- Managed storage
- Compressed table data plus metadata held in the vendor's object layer. Billed per terabyte per month, decoupled from compute on every modern cloud data warehouse.
- Data transfer charges
- Egress fees for moving result sets out of the vendor's region or cloud. Often the silent line item that breaks a budget when an analytics tool sits in a different region.
Once a team maps a workload onto these three buckets, the on-demand pricing versus committed-use trade-off becomes legible. Bursty exploratory analytics favor on-demand and per-second billing; steady production pipelines favor reserved instance pricing or slot commitments. The next three sections walk through how each vendor expresses the same three buckets.
Snowflake Pricing: Credits, Editions, and Storage
The credit-based platform prices compute through a virtual warehouse that consumes credits as it executes queries, loads data, and performs other DML operations, with the billed cost equal to consumed credits multiplied by the per-credit rate for the account's edition and region (per docs.snowflake.com). Warehouse credit consumption scales with warehouse size: each step up the t-shirt sizing ladder roughly doubles credits per hour. The current per-credit dollar rate is published in the vendor pricing guide at snowflake.com/en/pricing-options, because rates vary by edition, region, and contract type.
Billing is per-second with a 60-second minimum, and a suspended warehouse accrues zero credits while idle, which makes auto-suspend the single most effective cost lever (per docs.snowflake.com cost-understanding-compute). Teams running bursty workloads can set auto-suspend windows as short as 60 seconds; the idle-time behavior is essentially free.
| Warehouse size | Credits per hour | Per-second billing minimum |
|---|---|---|
| X-Small | 1 | 60 seconds |
| Small | 2 | 60 seconds |
| Medium | 4 | 60 seconds |
| Large | 8 | 60 seconds |
| X-Large | 16 | 60 seconds |
Account edition shapes the per-credit price: Standard, Enterprise, Business Critical, and Virtual Private (VPS) options each carry a different unit cost, with Business Critical and VPS adding governance and isolation features that justify the premium for regulated workloads (per docs.snowflake.com intro-editions). Storage is separate from compute and billed on compressed data volume, with rates that differ by Capacity versus On Demand account type and by region. Storage tiers split into active data, Time Travel retention, and Fail-safe recovery, and each tier accumulates on the same per-terabyte rate. For teams comparing analytics delivery models, the related discussion in self-service BI versus traditional analytics covers how compute economics shape downstream tool choice.
BigQuery Pricing: On-Demand and Capacity Models
The serverless query platform offers two compute pricing model options for running queries: on-demand pricing charges per tebibyte of query bytes processed by each query, and capacity pricing slots charge for compute capacity measured in slot-hours over time (per cloud.google.com/bigquery/pricing). The first 1 TiB of query data processed per month is free under on-demand pricing, which makes the service attractive for low-volume exploratory analytics where teams do not want to provision dedicated compute.
The serverless compute model auto-allocates resources up to roughly 2,000 concurrent slots on on-demand accounts, so query throughput scales with available pool capacity rather than a fixed cluster size (per cloud.google.com/bigquery/pricing). Capacity pricing, sometimes referenced under the older "flat-rate" label in legacy documentation, suits steady production workloads where a slot commitment yields predictable monthly spend and avoids the per-query variability of on-demand mode.
| Dimension | On-demand | Capacity pricing slots |
|---|---|---|
| Billing unit | Tebibytes scanned per query | Slot-hours reserved |
| Free tier | First 1 TiB/month free | None |
| Concurrency ceiling | ~2,000 concurrent slots | Defined by reservation |
| Idle behavior | No charge between queries | Pay for reserved slots regardless of use |
| Best fit | Bursty or unpredictable query volumes | Steady, predictable production pipelines |
Storage on the service is billed separately at a per-gigabyte rate for active and long-term tables, and streaming ingestion carries its own per-row line item that surprises teams who instrument event pipelines without budgeting for it (per cloud.google.com/bigquery/pricing). Cross-region data transfer charges apply when result sets leave the source region.
Redshift Pricing: Provisioned vs Serverless
Amazon Redshift offers two deployment options that share a query engine but bill on completely different primitives: a provisioned cluster starting at $0.543 per hour, and a serverless compute model beginning at $1.50 per hour (per aws.amazon.com/redshift/pricing). Provisioned mode targets steady-state workloads where a known cluster footprint can absorb the daily query load; serverless mode targets intermittent or experimental workloads where the per-second billing model and zero idle charges win the math.
The serverless option charges only for compute capacity on a per-second basis with no charges during idle periods, which makes it functionally similar to the auto-suspend pattern on the credit-based platform's side of the comparison (per aws.amazon.com/redshift/pricing). The provisioned cluster billing model, by contrast, keeps meter running as long as the cluster is up, regardless of query activity.
RA3 node types decouple compute from managed storage, so a provisioned cluster scales storage independently through the managed storage tier billed per terabyte per month. Reserved instance pricing applies to the clusters under 1-year and 3-year commitment terms, with discounts that reward steady-state forecasting (per aws.amazon.com/redshift/pricing).
| Dimension | the dedicated cluster | Serverless compute model |
|---|---|---|
| Starting rate | $0.543/hr | $1.50/hr |
| Billing increment | Hourly | Per-second billing |
| Idle cost | Cluster meter runs while up | No charges during idle periods |
| Commitment discounts | Reserved instance pricing (1-year, 3-year) | None published |
| Storage | Managed storage via RA3 | the storage tier included |
Side-by-Side Pricing Comparison
A cross-platform view of cloud data warehouse pricing should compare primitives, not headline rates. The table below maps each vendor onto the same six dimensions, with qualitative descriptors where the vendors do not publish directly comparable figures. Idle-time behavior and the storage and egress lines often dominate the monthly bill more than the headline compute rate suggests.
| Dimension | Snowflake | BigQuery | Redshift |
|---|---|---|---|
| Compute billing unit | Credits per second | TiB scanned or slot-hours | Hourly (provisioned) or per-second (serverless) |
| Idle-time behavior | Zero credits when suspended | No charge between on-demand queries | Provisioned meter runs; serverless free when idle |
| Storage billing | Per TB/month on compressed data | Per GB/month, active vs long-term tiers | Per TB/month via the managed storage layer |
| Data transfer charges | Egress fees vary by region | Egress fees vary by region | Egress fees vary by region |
| Free tier | 30-day trial credits | First 1 TiB/month query free | Trial credits via AWS Free Tier |
| Minimum billing increment | 60 seconds per warehouse | 10 MB per query (on-demand) | 1 second (serverless), 1 hour (provisioned) |
When to Choose Each Platform
The right platform follows from the workload shape, not from a generic rate comparison. Three decision triggers, anchored to the compute pricing model and idle behavior each vendor enforces, narrow the field quickly.
- Choose the credit-based warehouse when workloads are bursty and auto-suspend savings offset the per-credit premium, or when Business Critical edition governance features (HIPAA, PCI, customer-managed keys) are non-negotiable. Per-second billing on suspended warehouses turns idle minutes into zero spend.
- Choose the serverless query platform when query volumes are unpredictable, the on-demand pricing model fits exploratory analytics budgeting, and the team is already operating inside Google Cloud. The first-TiB-free allowance absorbs small workloads with no commitment.
- Choose the AWS-native warehouse when the workload runs steady enough to justify reserved instance pricing on the cluster, the data already lives in S3, and the team needs the storage tier decoupled from compute via RA3. Serverless mode covers the intermittent secondary workload.
None of the three platforms is universally cheaper. The cheapest option is the one whose compute pricing model matches the actual query rhythm, with storage and egress costed in honestly rather than treated as rounding error.
Cost Optimization Tactics That Apply Across All Three
A handful of platform-agnostic levers reduce spend regardless of which vendor wins the architecture review. Each lever targets a known failure mode in cloud data warehouse billing.
- Partition and cluster large tables to shrink query bytes processed on per-byte models and to reduce slot consumption on capacity pricing slots. Google's own cost optimization guidance documents the technique at cloud.google.com cost optimization for the warehouse.
- Set aggressive auto-suspend or slot commitments to eliminate idle-time behavior waste. A virtual warehouse left running over a weekend can outspend the productive workweek it served.
- Co-locate storage and compute in the same region to drive data transfer charges toward zero. Cross-region storage and egress is the single most common surprise on a first cloud bill.
- Audit cloud services compute on the credit-based platform and streaming ingestion on the serverless platform as recurring bill surprises. Both line items can grow silently when integrations multiply.
- Tag every warehouse, project, and cluster by team or product so finance can attribute the storage layer and compute back to the workload that drove it. See related coverage in BI platforms compared for downstream consumer-side context.
