A data platform lead at a Bengaluru fintech spent three weeks building a spreadsheet comparing Redshift's per-node-hour pricing against BigQuery's per-TiB-scanned pricing against Synapse's Data Warehouse Units, trying to normalize all three into a single "cost per query" number. The spreadsheet was wrong the day it shipped, because the three platforms don't meter the same resource. Redshift bills you for a cluster sitting there whether or not it's busy. BigQuery bills you for bytes a specific query happened to scan. Synapse bills a bundled compute abstraction that doesn't map cleanly to either.
That's the real starting point for BigQuery vs Redshift vs Synapse in 2026: this isn't a feature-parity contest, it's a decision about which billing model and operational shape fits how your queries actually run — and, if you're leaning Synapse, whether you're picking a platform or a two-year bridge to Microsoft Fabric.
All three separate storage from compute at the architecture level, which is table stakes for a modern cloud warehouse. Where they diverge is how directly you control — and pay for — that compute.
BigQuery: Serverless only. No cluster to size. On-demand
bills per TiB scanned; flat-rate bills per
slot-hour if you pre-purchase capacity.
Redshift: Provisioned clusters (you pick node type/count)
OR Redshift Serverless (RPU-hours, billed per
second). You choose the operational model.
Synapse: Dedicated SQL Pools (DWU-based, you provision)
OR Serverless SQL Pools (pay-per-query). Also
ties into Spark Pools for big-data workloads.
Strategic successor is Microsoft Fabric.
The practical consequence: BigQuery removes the "did we size the cluster right" question entirely, Redshift makes you answer it explicitly (with Serverless as an escape hatch), and Synapse answers it twice — once for SQL and again for Spark — while also asking you to think about whether you're building on a platform Microsoft is actively migrating customers away from.
This is the section that gets consistently botched in vendor comparison pages, because the units genuinely don't convert.
BigQuery on-demand charges by data scanned per query — $6.25 per TiB scanned, with the first 1 TiB each month free, which rewards well-scoped queries with tight WHERE clauses and partition pruning, and punishes SELECT * habits hard. Flat-rate pricing exists for teams that want predictable monthly bills instead: you buy slots, and every query draws from that shared pool regardless of bytes scanned.
Redshift Serverless bills by RPU-hour: $0.375 per RPU-hour, billed per second, which means idle time between queries genuinely costs nothing, unlike a provisioned cluster sitting on. Provisioned Redshift instead bills by the hour per node, on-demand or reserved, so a cluster running 24/7 pays whether or not anyone's querying it — the classic trade of predictability against utilization efficiency.
Synapse's Data Warehouse Unit (DWU) is a bundle of technical cost factors used to price compute resources, with storage billed separately. Because DWU folds CPU, memory, and I/O into one abstracted number, it's the hardest of the three to reason about from first principles — you generally have to benchmark your own workload against different DWU tiers rather than predict cost analytically.
BigQuery on-demand: ~500GB scanned x $6.25/TiB = ~$3.05
Redshift Serverless: depends on RPU-seconds consumed,
not bytes -- same scan can cost
more or less depending on query
complexity and concurrency
Synapse Serverless: billed per TB processed, similar
shape to BigQuery but different
rate card and minimum charge floor
If you're evaluating Synapse in 2026, you're not just evaluating Synapse. Microsoft Fabric is the strategic direction for new analytics workloads, and Azure Synapse is not deprecated — but new customers should start with Fabric. That's a materially different situation from BigQuery or Redshift, where the platform you evaluate today is the platform you'll still be running in three years.
The concrete pressure point: when Azure Synapse Runtime 3.4 reaches its end-of-life on March 31, 2026, Microsoft strongly recommends customers plan their migration to Microsoft Fabric. Microsoft hasn't set a hard deprecation date for Synapse as a whole, but the direction of travel is explicit enough that a greenfield Synapse deployment in 2026 should be scoped as a Fabric migration project from day one, not treated as a twenty-year platform bet.
For teams already invested in Synapse, the migration story isn't a rewrite — most Synapse SQL and stored procedures carry over, and roughly 70 to 80 percent of artifacts and workloads migrate natively using Microsoft's migration assistants, with the remainder closer to copy-and-paste than a ground-up rebuild.
If there's one axis that cleanly separates these three, it's how serverless each one actually is by default rather than as an opt-in tier. BigQuery was serverless from day one — there has never been a BigQuery cluster to provision. Redshift and Synapse both bolted serverless options onto architectures that started as provisioned clusters, and the seams show in different ways: Redshift Serverless still inherits RA3-generation storage architecture underneath, and Synapse Serverless SQL Pools are a separate compute mode from Dedicated SQL Pools with their own feature gaps (no materialized views, more limited T-SQL support).
For spiky, unpredictable analytics workloads — a Zerodha-style trading desk running heavy ad hoc query bursts around market open and near-silence overnight — that architectural history matters more than the marketing page suggests, because "serverless" bolted onto a cluster-native system tends to retain cluster-native assumptions about warm-up time and minimum billing increments.
Pricing model and operational shape:
| Factor |
BigQuery |
Redshift |
| Default pricing unit |
Per TiB scanned (on-demand) |
Per node-hour or RPU-hour |
| Cluster sizing required |
Never |
Only in provisioned mode |
| Idle-time cost |
None (on-demand) |
None (Serverless), yes (provisioned) |
Ecosystem fit and platform trajectory:
| Factor |
Redshift |
Synapse |
| Best native integration |
AWS (Lambda, Glue, QuickSight) |
Power BI, Azure ML |
| Platform trajectory |
Stable, actively developed |
Being superseded by Fabric |
| Multi-cloud reach |
AWS only |
Azure only |
Choose BigQuery for spiky, unpredictable analytical workloads where you don't want to think about cluster sizing at all, and where per-query cost transparency (bytes scanned) is easier to reason about and optimize than an abstracted compute unit — this is usually the right default for teams with no existing cloud commitment.
Choose Redshift when your data platform is already deeply embedded in AWS-native tooling and the operational cost of managing a cluster (or Redshift Serverless) is outweighed by the tightness of that integration with Lambda, Glue, and QuickSight.
Choose Synapse only if you're already committed to Azure and Power BI and are prepared to treat it as a bridge — plan the eventual Fabric migration into your architecture roadmap now rather than discovering the pressure later, especially given the March 2026 Synapse Runtime 3.4 end-of-life date. For a genuinely new Azure-based analytics platform starting today, evaluate Fabric directly before defaulting to Synapse out of habit.
For Indian enterprises weighing all three without an existing multi-year AWS or Azure commitment, BigQuery's zero-cluster-sizing model and free 1 TiB/month tier make it the lowest-friction platform to prototype against before a longer procurement decision — a pattern that holds whether the eventual production workload lands on BigQuery or elsewhere.
INFORMATIONReferences and Further Reading
Discussion0