Editor’s note: We combine independent analysis, data collection, and hands-on testing to review data and AI tools. This comparison weighs pricing, architecture, performance, integrations, and AI features.
Quick verdict: We recommend Redshift for AWS-committed teams with steady 24/7 workloads and an engineer to tune it, and BigQuery for variable workloads, small teams, and zero infrastructure appetite. Redshift buyers accept 5 to 10 ops hours a month; BigQuery buyers accept five-figure billing spikes without guardrails.
In this Redshift vs BigQuery comparison, I’ll take a closer look at pricing, architecture, performance, data loading, and AI features to show which warehouse fits your stack.
Key Takeaways
- BigQuery on-demand costs $6.25 per TiB scanned; the $5/TB most comparisons quote died in July 2023
- Redshift Serverless runs $0.375 per RPU-hour; a provisioned RA3.4xlarge is $3.26 per hour on-demand
- A LIMIT clause does not cap a BigQuery bill; three runs of one documented query billed $9,847 in 22 seconds
- Redshift provisioned clusters need 5 to 10 engineer-hours a month for vacuum, sort keys, and WLM tuning
- Both ship GA generative SQL (Amazon Q on Redshift, Gemini in BigQuery), so AI is no longer a BigQuery-only argument
Redshift vs BigQuery at a Glance
Amazon Redshift is AWS’s data warehouse, sold as provisioned RA3 clusters you size yourself or as Serverless capacity billed in RPU-hours. Its edge is the deepest integration in the AWS ecosystem, from S3 and Glue to zero-ETL feeds out of Aurora, RDS, and DynamoDB. Reserved Instances reward teams that keep a cluster busy around the clock.
Google BigQuery is GCP’s serverless warehouse: no clusters to size, no nodes to patch, billing per TiB scanned on-demand or per slot-hour on Editions. Its edge is elasticity, native nested data, and a permanent free tier no provisioned rival matches.
| Dimension | Redshift | BigQuery |
|---|---|---|
| Architecture | Provisioned RA3 clusters or Serverless RPUs | Pure serverless, slot-based |
| Pricing model | Per node-hour or per RPU-hour | Per TiB scanned or per slot-hour (Editions) |
| Entry price | $0.375/RPU-hour Serverless; RA3.xlplus about $1.086/hour | $6.25/TiB on-demand; Standard edition $0.04/slot-hour |
| Free offer | $300 Serverless credit, expires in 90 days | 1 TiB queries + 10 GiB storage free every month, permanent |
| Storage | $0.024/GB-month managed storage | About $0.023/GiB-month logical; 50% discount after 90 days untouched |
| Max columns per table | 1,600 | 10,000 (including nested) |
| Generative AI | Amazon Q generative SQL | Gemini in BigQuery plus AI.GENERATE SQL functions |
| Zero-ETL and cross-cloud | Aurora, RDS, DynamoDB, SaaS sources; AWS only | Datastream CDC plus Omni reads against S3 and Azure Blob |
| Best for | Steady AWS workloads with engineers to tune them | Spiky workloads, small teams, multi-cloud data |
Every row traces to one design split: Redshift bills capacity you manage, BigQuery bills consumption Google manages. BigQuery’s free tier covers a 1 TiB query month indefinitely, while the cheapest always-on provisioned Redshift, a single RA3.xlplus at $1.086 per hour, bills about $790 a month before storage. Redshift Serverless narrows that for intermittent use, but its $300 trial credit still expires after 90 days.
Redshift’s 41 to 76% Reserved Instance discount only lands on a cluster you keep busy, and BigQuery’s $6.25 per TiB only stays cheap on partitioned, clustered tables.
1. Pricing: BigQuery Is Simpler, Redshift Is More Predictable
BigQuery on-demand has cost $6.25 per TiB scanned since July 2023, and most comparison articles still print the retired $5/TB rate. That stale figure understates Redshift vs BigQuery pricing math by 20% before you run a single query.
On-demand charges per TiB scanned; Editions charge per slot-hour with autoscaling between a baseline and a maximum, the model that replaced flat-rate slot commitments and Flex Slots:
- On-demand ($6.25/TiB scanned): low or irregular query volume on partitioned, clustered tables
- Standard edition ($0.04/slot-hour): ad-hoc analysis that needs a cost ceiling without enterprise features
- Enterprise edition ($0.06/slot-hour): production workloads needing autoscaling headroom and finer governance
- Enterprise Plus ($0.10/slot-hour): teams that genuinely need multi-region disaster recovery and workload isolation; easy to over-provision if you do not
Active logical storage runs about $0.023 per GiB-month with the first 10 GiB free, and any table or partition untouched for 90 days automatically drops to roughly $0.01. Physical storage billing charges about $0.04 per GiB-month on compressed bytes instead, which only pays off above roughly a 2:1 compression ratio, because time travel and fail-safe then bill separately. The always-free tier adds 1 TiB of queries and 10 GiB of storage every month, permanently.
Redshift bills compute two ways, per RPU-hour on Serverless or per node-hour on provisioned RA3:
- Serverless ($0.375/RPU-hour, 60-second minimum): bursty or intermittent workloads; base capacity spans 4 to 1,024 RPUs
- RA3.xlplus ($1.086/hour on-demand): the entry provisioned node for small steady clusters
- RA3.4xlarge ($3.26/hour on-demand): the mainstream provisioned node
- RA3.16xlarge ($13.04/hour on-demand): large clusters consolidating heavy BI and ETL
Managed storage adds $0.024 per GB-month. Reserved Instances cut steady 24/7 compute costs by 41 to 76% versus on-demand, Concurrency Scaling includes roughly one free burst hour per day, and new Serverless users get a $300 credit that expires after 90 days.
| Cost lever | Redshift | BigQuery |
|---|---|---|
| Query compute | $0.375/RPU-hour or node-hours | $6.25/TiB or $0.04 to $0.10/slot-hour |
| Storage | $0.024/GB-month | $0.023/GiB-month, halved after 90 idle days |
| Committed-use discount | RIs save 41 to 76% | Edition slot commitments |
| Free offer | $300 for 90 days | 1 TiB + 10 GiB monthly, forever |
A Worked Example: 2 TB Warehouse, 200 GB Scanned Daily
BigQuery on-demand bills about 6 TiB of scans a month here: $37.50 in queries at list rate plus about $47 in storage, roughly $84 before the always-free 1 TiB trims $6.25 off. The same workload on Redshift Serverless, at 2 hours of 8-RPU compute daily, runs $180 in compute plus $48 in storage, about $228. Flip the duty cycle and the answer flips with it: a cluster busy around the clock on Reserved Instances undercuts paying $6.25 for every scanned TiB. The crossover is duty cycle, not warehouse size.
A LIMIT clause does not cap a BigQuery bill, because on-demand billing charges for data referenced, not rows returned. Documented cases include $9,847 billed across three 509.89 TB runs in 22 seconds against a public dataset, and an $18,000 month in which three LIMIT-capped queries each cost over $5,000. Set maximum bytes billed and custom quotas before anyone touches a large table.
Predictable heavy workloads price better on Redshift Reserved Instances; irregular or low-volume workloads price better on BigQuery, provided the quotas go in on day one.
2. Architecture and Maintenance: Zero-Ops vs Fine Control
Practitioners budget 5 to 10 hours a month to run a provisioned Redshift cluster: vacuuming, distribution and sort key design, and WLM queue tuning. BigQuery has no equivalent line item, because Google allocates slots, handles maintenance, and never asks you to size a node.
Distribution and sort keys pin the physical layout for repeated joins, WLM queues isolate ETL from dashboard traffic, and a tuned cluster delivers predictable latency for a known workload. The debt also compounds silently: a monotonically increasing sort key becomes useless for pruning as a table grows, and it makes every VACUUM progressively more expensive to run.
Discord’s nightly Redshift vacuum windows grew past 12 hours, failed runs pushed maintenance beyond 24, and slipping data-freshness SLAs drove the move to BigQuery. That is unmanaged growth at very large scale, not the average team’s experience.
Redshift Serverless is the middle path: RPU billing removes cluster sizing and most of the vacuum ritual while keeping the AWS integration. New provisioned clusters have had public access disabled by default since January 10, 2025, and Redshift stopped accepting new Python UDFs after October 30, 2025 (existing ones keep running; AWS points to Lambda UDFs instead).
The standard Redshift mitigations are scoping VACUUM to specific problem tables, auditing sort keys on high-growth tables, raising wlm_query_slot_count for VACUUM when SVV_VACUUM_SUMMARY shows high sort partitions, and letting Auto WLM allocate resources instead of hand-tuned queues. Maintenance windows that keep outgrowing your ingestion SLA are a signal to re-architect, not to tune harder.
BigQuery offers no tuning knobs, which leaves fewer levers when a query misbehaves and shifts the monthly discipline from performance tuning to cost control: partitioning, clustering, and quotas.
A 3-person data team without a platform engineer should default to BigQuery; a team with dedicated data engineering keeps more control per dollar on Redshift.
3. Performance and Concurrency: The Benchmark Wars Are Over
The famous “Redshift is 6x faster” number comes from a 2016 TPC-DS benchmark that AWS ran itself: 99 queries against a 30 TB dataset, Redshift ahead on 94 of them, and 9 queries that would not run on BigQuery at all. A GigaOm study on the same 30 TB TPC-DS suite put the gap near 5x on execution time and cost. Both results are vendor-influenced, and both predate RA3 nodes, BigQuery Editions, and autoscaling slots. Neither number survives 2026 conditions, where the fastest platform flips by query type, dataset size, and billing model.
A tuned Redshift cluster with warm caches wins repeated, join-heavy workloads, the shape that distribution and sort keys exist to serve. BigQuery wins wide ad-hoc scans with zero warmup, because Google allocates slots to a fresh query immediately and there is no cluster to warm.
Redshift WLM caps out at 50 query slots across all queues on a cluster, the structural ceiling teams hit before they need Concurrency Scaling or Serverless for bursty BI traffic. Concurrency Scaling adds transient clusters past that point, defaulting to one extra cluster and configurable higher, with roughly one free hour of credits a day and per-second billing at a one-minute minimum after that. BigQuery Editions autoscale slot capacity between a configured baseline and maximum, so a burst of dashboard users draws more slots instead of queueing. Both platforms serve repeated identical queries from a result cache, and BigQuery’s BI Engine adds an in-memory layer for dashboard tools like Looker.
No benchmark screenshot should decide a BigQuery vs Redshift purchase. Steady, repeated, join-heavy workloads favor a tuned Redshift cluster; spiky, exploratory scans favor BigQuery; a week of your own queries settles it faster than any TPC-DS chart.
4. Data Loading, Zero-ETL, and Open Formats
Redshift’s zero-ETL integrations are GA from Aurora MySQL, Aurora PostgreSQL, RDS for MySQL, PostgreSQL, and Oracle, DynamoDB, and Oracle Database@AWS, plus application sources including Salesforce, SAP, ServiceNow, and Zendesk. Operational data replicates into the warehouse continuously with no pipeline code, and the source systems stay live and updatable. For an AWS shop, that is the shortest path from production database to queryable table either vendor offers.
Datastream handles CDC-style ingestion from operational databases into BigQuery proper, which is the closer match to Redshift’s zero-ETL feeds. BigQuery Omni goes further than anything Redshift has: it runs BigQuery compute directly against data sitting in Amazon S3 or Azure Blob Storage through BigLake tables (renamed Lakehouse on April 20, 2026, though APIs, client libraries, and IAM roles still say BigLake), so only query results cross the cloud boundary. Cross-cloud joins run under one SQL syntax and one IAM and governance model, which keeps both egress cost and data-residency exposure down versus copying the data in. Redshift has no cross-cloud equivalent.
Both platforms reach Apache Iceberg from opposite directions. BigQuery creates and manages Iceberg tables with plain DDL through its Lakehouse runtime catalog and an Iceberg REST catalog endpoint, and tables created from either side share one catalog and namespace, so Spark, Flink, and Trino query the same data without a second copy. AWS routes Redshift to Iceberg through Amazon S3 Tables and the SageMaker Lakehouse integration, GA since March 13, 2025, which exposes one copy of the data to Redshift, Athena, EMR, and Glue.
Neither platform covers the long tail of SaaS sources natively, Redshift’s application-source list aside; both ecosystems still lean on partner ETL tools like Fivetran.
Single-cloud AWS shops get the cleanest operational-data path on Redshift; multi-cloud or lakehouse-leaning teams get more optionality on BigQuery.
5. AI and ML: Both Ship GA Copilots Now
Amazon Q generative SQL went GA in Redshift Query Editor v2 in September 2024, after a preview that logged more than 85,000 generated queries, and reached US East (Ohio) and Asia Pacific (Seoul) by February 2025. It turns natural-language prompts into SQL using your schema metadata and query-pattern analysis, and AWS says it does not use customer queries or schemas to train the underlying foundation models. The old assumption that warehouse AI means choosing Google is out of date.
BigQuery’s stack is broader. Gemini in BigQuery generates and explains SQL and Python and assists data exploration in the console. Below the copilot layer, the GA AI.GENERATE and AI.GENERATE_TABLE functions run Gemini 3.0 inference inside a SQL statement, AI.EMBED and AI.SIMILARITY produce and compare embeddings, and VECTOR_SEARCH scales semantic search across millions or billions of rows using precomputed embeddings and vector indexes. BigQuery ML trains and serves classical models in SQL on top of that, with no export to a separate vector database anywhere in the stack.
Redshift covers predictive ML through Redshift ML, where CREATE MODEL hands training to SageMaker and brings the model back for in-SQL inference. That works for churn scores and forecasts, but it is a bridge to another service rather than an in-warehouse model catalog.
Analysts who do not write SQL fluently get a GA copilot on either platform, grounded in their own schema rather than generic SQL. Teams that want embeddings, semantic search over customer records, or generative inference running inside the warehouse itself get that depth only on BigQuery.
Call it parity on “help me write SQL”: BigQuery leads on in-warehouse inference and vector work, while Redshift covers classic predictive ML through SageMaker.
6. Semi-Structured Data and Hard Limits
BigQuery models event data natively: nested and repeated ARRAY and STRUCT fields, a JSON type, up to 10,000 columns per table including nested ones, and 15 levels of nesting depth. A raw product-analytics event lands in one table without flattening. The 10,000-column limit is cumulative across joined tables, subqueries, CTEs, and temp tables in a single query, so two individually compliant wide tables can still fail a JOIN together.
Redshift handles the same data through the SUPER type, which stores schemaless JSON parsed once at load and queried through PartiQL dot notation and unnesting. It works, but it is a second query dialect bolted onto standard SQL, and SUPER is the least mature of the major warehouses’ semi-structured approaches next to BigQuery’s nested types and Snowflake’s VARIANT. The hard caps bite too: 1,600 columns per table (1,597 for Glue Data Catalog external tables with pseudocolumns enabled) and 400 SORTKEY columns, PostgreSQL inheritances that wide feature tables and denormalized event schemas can actually hit.
Redshift-to-BigQuery moves stall on SUPER and GEOMETRY columns, which have no direct BigQuery equivalent, and you re-map DISTKEY and SORTKEY designs by hand to partitioning and clustering. The dialect gap cuts in both directions, so budget for query rewrites whichever way you move.
Heavy JSON and event workloads fit BigQuery’s model natively; classic star schemas with a few hundred flat columns fit both platforms equally well.
7. Ecosystem and Lock-In: The Question Is Which Cloud You Already Pay
Teams already committed to AWS or GCP rarely cross clouds for the warehouse alone, because egress fees and a second IAM model outweigh any single feature delta. Answer the cloud question first and half the shortlist disappears.
Redshift’s pull is the AWS stack around it: S3 for the lake, Kinesis for streams, Glue for catalogs and ETL, SageMaker for ML, Lake Formation for governance, and the zero-ETL feeds covered in criterion 4. The trade is that the story ends at the AWS boundary; there is no Redshift equivalent of running compute against another cloud’s storage.
BigQuery’s orbit is Looker for BI, Dataplex for governance, Vertex AI for ML, and Omni as the partial multi-cloud answer, reaching into S3 and Azure Blob without moving the data.
SQL dialect differences and UDF stacks make queries expensive to move, and Redshift’s October 30, 2025 Python UDF cutoff forces a Lambda rewrite even for teams staying put. Zero-ETL feeds are a soft lock of their own: the pipeline you never built is also the pipeline you never budgeted to migrate. The type and key incompatibilities from criterion 6 are the same bill in another form, since a move pays for query rewrites before it pays for egress. Egress pricing then taxes the exit whichever direction you leave.
Snowflake is the cloud-neutral hedge, running on AWS, Azure, and GCP with serverless ergonomics close to BigQuery’s, and its VARIANT type beats Redshift’s SUPER on semi-structured maturity. Databricks starts from the lakehouse rather than the warehouse and suits teams whose data science load outweighs their BI load. Cloud commitment decides first, workload shape second, features third.
The Bottom Line: Should You Pick Redshift or BigQuery?
- Pick Redshift if you run an AWS stack, your BI and ETL load is steady around the clock, and data engineers are on staff: Reserved Instances at 41 to 76% off on-demand make a tuned RA3 cluster the cheapest option, and you accept 5 to 10 ops hours a month as the price
- Pick BigQuery for variable or exploratory workloads, small teams, JSON-heavy event data, or data spread across clouds: you accept that billing guardrails (maximum bytes billed, custom quotas) are your responsibility from day one
- Unsure and low volume: BigQuery’s permanent free tier of 1 TiB queries and 10 GiB storage a month is the cheapest way to find out, since it never expires; Redshift’s $300 Serverless credit runs out after 90 days, which makes it a deadline, not a home
Load a week of real workload into both free offers and measure your own scan volume and compute hours against the rates above. Your duty cycle, not a published benchmark, decides which invoice is smaller, and a week of measurement costs nothing inside either free offer.
Prices current as of September 2026.
FAQ
Is BigQuery still $5 per TB queried?
No. BigQuery on-demand has charged $6.25 per TiB of data processed in most regions since Google’s July 2023 pricing restructuring, which also replaced flat-rate slots and Flex Slots with Editions. Comparison articles quoting $5/TB are working from pre-2023 numbers, which understates a scan-heavy budget by 20%.
Does a LIMIT clause reduce BigQuery costs?
No. On-demand billing charges for the bytes the query plan references, not the rows returned, so a LIMIT 100 against an unpartitioned table bills the full scan. One documented case referenced 509.89 TB per run and billed $9,847 across three runs in 22 seconds. Use the dry-run estimate, set maximum bytes billed, and apply custom quotas per user and project.
Is Redshift faster than BigQuery?
The widely cited 5 to 6x Redshift advantage comes from a 2016 AWS-run TPC-DS test and a GigaOm study, both vendor-influenced and both older than RA3, Editions, and autoscaling slots. No universal winner survives current conditions: a tuned Redshift cluster wins repeated join-heavy work, BigQuery wins wide ad-hoc scans with no warmup. Benchmark a representative slice of your own workload instead.
Which is better for AI: Redshift or BigQuery?
Both ship GA copilots: Amazon Q generative SQL (GA September 2024) and Gemini in BigQuery. BigQuery goes deeper in-warehouse, with GA AI.GENERATE, AI.GENERATE_TABLE, AI.EMBED, and AI.SIMILARITY functions running Gemini 3.0 inference in SQL plus native VECTOR_SEARCH. Redshift handles predictive ML through SageMaker-backed Redshift ML instead.
Can BigQuery query data in AWS S3?
Yes. BigQuery Omni runs BigQuery compute against data in Amazon S3 or Azure Blob Storage through Lakehouse (formerly BigLake) tables, and only the query results cross the cloud boundary. Redshift has no equivalent reach into GCP; its external-data story runs through S3 Tables and SageMaker Lakehouse inside AWS.
Is Redshift Serverless cheaper than a provisioned cluster?
It depends on duty cycle. Below roughly 70% utilization or 8 to 10 active hours a day, Serverless at $0.375 per RPU-hour avoids paying for idle nodes. For steady 24/7 workloads, provisioned RA3 with 1- or 3-year Reserved Instances runs 41 to 76% cheaper than on-demand, which Serverless cannot match. Multi-AZ or base capacity above 1,024 RPUs also require provisioned RA3.
Comments 0 Responses