Comparing BigQuery vs Redshift vs Synapse on cost is less about which is cheapest in the abstract and more about which billing model fits your query pattern. BigQuery leans toward paying for the data each query scans, Redshift and Synapse lean toward paying for provisioned compute capacity that runs whether or not you query it. Match the model to your workload and any of the three can be the cheapest; mismatch it and any of them can be the most expensive.
This comparison is part of our complete guide to cloud storage and data cost optimization, the cluster pillar it links up to. Choosing and tuning a warehouse is a See and Cut decision under our See, Cut, Lock, Run method, and the broader tuning playbook is in how to optimize data warehouse costs.
Scan-based pricing rewards infrequent, well-pruned queries and punishes unbounded full-table scans. Capacity-based pricing rewards steady, high-utilization workloads and punishes a cluster left running idle. Your query pattern, not the logo, decides which is cheaper.
How BigQuery prices
Google BigQuery separates storage from compute and offers two main compute models: an on-demand model where you pay by the volume of data each query scans, and a capacity model where you buy dedicated query processing slots for a period. Storage is billed per gigabyte with a lower rate for data not modified recently. The on-demand model is excellent for spiky, occasional analytics because you pay nothing for compute when idle, but a few badly written full-scan queries over large tables can produce surprising bills. Partitioning and clustering tables to limit bytes scanned is the primary cost lever.
How Amazon Redshift prices
Redshift's traditional model is provisioned: you pay for cluster nodes by the hour whether or not queries run, with the option of reserved pricing for steady workloads. Its serverless model instead bills by capacity consumed while queries execute, measured in compute units, which removes the idle-cluster cost. Storage on the managed-storage instance types is billed separately. Redshift tends to be cost-effective for steady, high-utilization analytics on a right-sized cluster, and expensive when a large provisioned cluster sits mostly idle. Reserved-instance style commitments reward predictable, always-on use.
Not sure which warehouse is bleeding money?
Our cloud cost audit reads your query and utilization patterns, models the cost of each warehouse option against your real workload, and shows where the spend is avoidable. On the performance model, you pay only from realized savings. No savings, no fee.
Book a cloud cost audit →How Azure Synapse prices
Azure Synapse Analytics offers both a provisioned dedicated SQL pool, billed by the data warehouse units you allocate while the pool is online, and a serverless SQL pool billed by data processed per query, similar in spirit to BigQuery's on-demand model. Storage is billed separately. The dedicated pool can be paused to stop compute charges when not in use, which is a meaningful lever for analytics that run on a schedule rather than continuously. As with the others, an always-on dedicated pool at low utilization is the expensive failure mode.
Where each gets expensive, and how to choose
The pattern across all three is the same: idle provisioned capacity and unbounded scans are what drive cost, not the headline rate. Choose scan-based or serverless pricing when analytics are spiky or occasional and you can prune queries well. Choose provisioned capacity with a commitment when the warehouse runs steadily at high utilization. Whichever you pick, the savings come from the same disciplines: partition and cluster to cut bytes scanned, pause or scale down idle capacity, and keep cold historical data on cheaper storage. Those disciplines are detailed in how to optimize data warehouse costs, and the broader storage tiering logic in how to build a storage lifecycle policy.
| Warehouse | Primary compute model | Cheapest when | Expensive when |
|---|---|---|---|
| BigQuery | On-demand bytes scanned, or slots | Spiky queries, well-pruned tables | Unbounded full-table scans |
| Redshift | Provisioned nodes, or serverless units | Steady high-utilization clusters | Large cluster left idle |
| Synapse | Dedicated pool DWUs, or serverless | Scheduled runs with pausing | Always-on pool at low utilization |
Pricing models, serverless options, and pause and commitment features for BigQuery, Amazon Redshift and Azure Synapse change regularly. Verify current rates, units, and features on each provider's pricing pages before modeling a migration or commitment, as of May 2026.
Do not forget storage and data transfer
Comparisons usually fixate on the compute rate and ignore the two lines that quietly accumulate underneath it: storage and data transfer. All three warehouses bill stored data separately from compute, and a warehouse holding years of history pays for that capacity every month whether or not anyone queries the old partitions, which is why lifecycle tiering of cold partitions matters as much as query tuning. Data movement is the other trap. Loading data in is usually cheap, but shipping query results out to a BI tool, exporting to another region, or feeding a downstream system across a boundary incurs egress on the same principles as any other workload, covered in data egress charges explained. When you model a warehouse decision, add the storage footprint and the expected egress to the compute estimate, because a warehouse that wins on compute rate can lose once the full picture is on the table.
The Cloud Storage and Egress Cost Playbook includes the query-pattern worksheet we use to model warehouse cost against a real workload. It is the downloadable companion to this comparison.
Commitments cut the rate on all three
Once you know a warehouse will run steadily, a commitment lowers the rate the same way reservations do for compute. BigQuery sells capacity commitments for its slot-based model, Redshift offers reserved pricing on provisioned clusters, and Azure discounts dedicated Synapse capacity through its reservation program. The rule is identical to compute commitments: buy only against the steady-state floor, never against a peak or an un-tuned baseline. A capacity commitment bought before you have pruned scans and removed idle time simply locks in the waste for the term, exactly the trap we warn about across every cluster. Tune the workload first, establish the true floor of capacity it needs continuously, commit to that, and keep burst and experimental analytics on the on-demand or serverless model. The general discipline of committing only on a clean baseline is covered in our work on commitment management, and it applies to data warehouses as squarely as it does to virtual machines.
The short version
BigQuery favors scan-based pricing, Redshift favors provisioned capacity, and Synapse offers both with a pausable dedicated pool. None is universally cheapest; the winner is the model that matches your query pattern, and the savings in all three come from pruning scans, removing idle capacity, and tiering cold data. For the full tuning method, read how to optimize data warehouse costs. When you want the comparison modeled against your real spend, that is what our rightsizing and waste elimination service delivers.