BigQuery vs Redshift vs Synapse for 2026: how each one bills a query, how serverless each really is, and where Fabric fits for Azure teams.
A data platform lead at a Bengaluru fintech spends three weeks building a spreadsheet that compares Redshift's per-node-hour pricing, BigQuery's per-TiB-scanned pricing, and Synapse's Data Warehouse Units. The goal is a single "cost per query" number. The spreadsheet is wrong the day it ships, because the three platforms do not meter the same resource. This is a composite scenario, but the mistake is common.
Redshift provisioned bills for a cluster whether or not it is busy. BigQuery bills for the bytes a query happened to scan. Synapse bills a bundled compute unit that maps cleanly to neither. So BigQuery vs Redshift vs Synapse in 2026 is not a feature-parity contest. It is a decision about which billing model and operational shape fits how your queries actually run, and, if you lean toward Azure, whether you are choosing a platform or a bridge to Microsoft Fabric.
All three separate storage from compute. They diverge on how directly you control, and pay for, that compute. BigQuery removes sizing entirely, Redshift lets you choose between provisioned and serverless, and Synapse splits compute into several pools.
The practical consequence is that BigQuery removes the "did we size the cluster right" question, Redshift makes you answer it (with Serverless as an escape hatch), and Synapse asks it twice, once for SQL and again for Spark.
Each platform bills a different unit, so you must convert your workload into each unit instead of comparing sticker prices. The mistake in most vendor comparisons is treating the units as interchangeable.
BigQuery on-demand charges for data scanned. The first 1 TiB per month is free, and the rate beyond that is set per region on Google's pricing page, so check the current figure before you model anything. Because BigQuery is columnar, you pay only for the columns you reference, and partition pruning reduces bytes further. Capacity pricing exists for teams that want predictable bills: you buy or autoscale slots and every query draws from that pool.
Redshift Serverless bills per RPU-hour, per second. At the us-east-1 list price of $0.375 per RPU-hour, a query that uses 32 RPUs for 60 seconds costs about $0.20. Idle time between queries costs nothing on Serverless, unlike a provisioned cluster that runs 24/7. Base capacity can be set low (as little as 4 RPU in supported regions), but a higher base speeds up heavy queries.
Synapse prices Dedicated SQL Pools in Data Warehouse Units, a bundle of CPU, memory, and I/O, with storage billed separately. Serverless SQL Pools bill per TB processed. Because DWU abstracts three resources into one number, you generally benchmark your own workload at different DWU levels instead of predicting cost.
Use a dry run to see what BigQuery will charge before you spend anything:
## Show bytes a query would scan, without running itbq query --dry_run --use_legacy_sql=false \ 'SELECT order_id, amount FROM `shop.orders` WHERE order_date = "2026-09-01"'Then cap the damage on scheduled or ad hoc jobs:
## Fail the job if it would bill more than about 100 GBbq query --use_legacy_sql=false \ --maximum_bytes_billed=100000000000 \ 'SELECT order_id FROM `shop.orders`'Partitioning and clustering are the biggest levers on BigQuery cost:
CREATE TABLE shop.orders_pPARTITION BY DATE(order_ts)CLUSTER BY customer_id ASSELECT * FROM shop.orders;As an illustration, a 500 GB scan is about 0.49 TiB, so it costs roughly 0.49 times the on-demand rate (less if you still have free TiB for the month). The same query on Redshift Serverless depends on RPU-seconds, not bytes, so complexity and concurrency matter more than size.
Match the platform to how your queries arrive. Spiky ad hoc analytics favour per-query billing, steady dashboards favour reserved capacity, and tightly integrated cloud stacks favour the native warehouse.
Synapse is supported and not being retired on a published date, but Microsoft is putting new investment into Microsoft Fabric. If you are evaluating Synapse in 2026, you are also evaluating a platform in maintenance mode, which is a different situation from BigQuery or Redshift, where today's choice is also the long-term platform.
Be careful with one date you may see quoted. Synapse Runtime for Apache Spark 3.4 was retired on March 31, 2026, and Microsoft recommended upgrading to Spark 3.5. That is a Spark version lifecycle event, not the end of Synapse. It is, however, a good example of the maintenance burden: runtimes age out, and new Spark features arrive in Fabric first.
For teams already on Synapse, the migration story is not a ground-up rewrite. Microsoft's migration tooling and partners say a large share of artifacts (figures of 70 to 80 percent are quoted) can be moved with assistance, and most T-SQL carries over. Connections, credentials, triggers, and governance setup still need manual work, so plan migration waves and treat any percentage as a vendor estimate. For a genuinely new Azure analytics platform, evaluate Fabric directly before defaulting to Synapse out of habit.
BigQuery is serverless by design, while Redshift and Synapse added serverless options to products that began as provisioned clusters. That history shows up in feature gaps and billing details, so read the fine print before you assume "serverless" means "no capacity decisions".
For spiky workloads, such as a trading desk running heavy ad hoc bursts around market open and near-silence overnight, this matters more than the marketing page suggests. Serverless added to a cluster-native system tends to keep cluster-native assumptions about warm-up and minimum billing increments, so test with your real query pattern.
Pricing model and operational shape:
| Platform | Pricing unit | Idle cost |
|---|---|---|
| BigQuery | Per TiB scanned, or slot-hour | None on-demand |
| Redshift | Node-hour or RPU-hour | None Serverless, yes provisioned |
| Synapse | DWU (dedicated), per TB (serverless) | Yes for dedicated pools |
Ecosystem fit and trajectory:
| Platform | Best native fit | Trajectory |
|---|---|---|
| BigQuery | GCP, Looker, Vertex AI | Actively developed |
| Redshift | AWS Lambda, Glue, QuickSight | Actively developed |
| Synapse | Power BI, Azure ML | Maintenance mode, Fabric |
Multi-cloud reach is limited on all three. BigQuery Omni can query data in S3 and Azure Blob Storage with a reduced feature set, but the warehouse itself runs on one cloud. If you need a cloud-neutral warehouse, look at Snowflake or Databricks SQL, and accept a different pricing model and a separate vendor relationship.
Choose BigQuery for spiky, unpredictable analytical workloads where you do not want to think about cluster sizing, and where per-query transparency (bytes scanned) is easier to reason about than an abstract compute unit. This is usually the right default for teams with no existing cloud commitment. Enforce maximum_bytes_billed, partition large tables, and review the most expensive queries weekly.
Choose Redshift when your data platform is already embedded in AWS-native tooling and the integration with Lambda, Glue, and QuickSight outweighs the effort of managing a cluster. Start on Redshift Serverless, measure RPU-hours for a month, and move to provisioned RA3 with reserved pricing only if utilisation is steady and high.
Choose Synapse only if you are committed to Azure and Power BI and are ready to treat it as a bridge. Put the Fabric migration on your architecture roadmap now, and track Spark runtime retirement dates so a version bump does not become an emergency.
For Indian enterprises weighing all three with no existing multi-year AWS or Azure commitment, BigQuery's zero-sizing model and free monthly TiB make it the lowest-friction platform to prototype against. Check regional availability (Mumbai, asia-south1 for BigQuery, ap-south-1 for Redshift, Central India for Synapse) and data residency rules before you commit, since RBI and sector regulators may constrain where payment data can live.
š Remember: Prices change often. Re-run the numbers against each provider's current pricing page, and benchmark with your own queries before you sign a commitment.
NoteReferences and Further Reading
- BigQuery pricing - Official on-demand and capacity pricing
- Amazon Redshift pricing - Provisioned and Serverless rate cards
- Azure Synapse Analytics documentation - Dedicated and Serverless SQL pools
- Migrate from Synapse to Microsoft Fabric - Fabric documentation and migration guidance
Not without normalising carefully, because they meter different resources. BigQuery on-demand bills for bytes a query scans, Redshift provisioned bills for a cluster that is running whether or not it is busy, and Redshift Serverless bills RPU-seconds consumed, so the same query can cost more or less depending on complexity and concurrency, not just data volume.
No end-of-life date has been announced, but Synapse is in maintenance mode while Microsoft concentrates new investment on Microsoft Fabric. Do not confuse this with the Synapse Spark runtime 3.4 retirement on March 31, 2026, which was a Spark version lifecycle event and not the end of Synapse itself.
No. BigQuery on-demand bills for the bytes read from the columns you reference, and LIMIT is applied after the scan. To cut cost, select only the columns you need and filter on a partition column so whole partitions are pruned. Use a dry run to see the bytes before you run the query.
Set a maximum bytes billed limit on the query or job, add project-level or user-level custom quotas, and run dry runs in CI for scheduled queries. A query that would scan more than the limit fails without charge instead of running.
Only BigQuery. It has always been serverless. Redshift Serverless and Synapse Serverless SQL Pools both added serverless modes to products that began as provisioned clusters, so you still need to understand base capacity, scaling behaviour, and minimum billing increments.
Discussion0