BigQuery vs Redshift

Quick verdict

BigQuery is Google Cloud's serverless data warehouse. Data is stored in a columnar format, separately from compute, and replicated across zones. Queries run on slots, virtual compute units that BigQuery allocates; you either let projects draw slots on demand and pay per TiB processed, or buy capacity in one of three editions (Standard, Enterprise, Enterprise Plus) through reservations. Objects are addressed as project.dataset.table.

Amazon Redshift is AWS's data warehouse, with SQL descended from PostgreSQL. A provisioned cluster has a leader node and compute nodes; AWS recommends RG (Graviton based) or RA3 nodes, both using Redshift managed storage so compute and storage are sized separately, while DC2 is listed as previous generation. Redshift Serverless measures capacity in Redshift Processing Units (RPUs, 16 GB of memory each) and scales automatically from a base capacity you set. Objects are addressed as database.schema.table.

Side by side

Key differences

Two kinds of serverless

BigQuery has no clusters in either billing model. On demand, a project uses slots from a shared pool and pays for bytes processed. With editions, you create reservations, assign projects to them, and set an optional baseline plus a maximum; Google documents that autoscaling adds slots in multiples of 50 and that you pay for the slots scaled, not the slots used.

Redshift Serverless is closer to an automatically sized warehouse. You create a workgroup with a base capacity: 4 RPUs, or 8 to 512 in steps of 8, and up to 1,024 in US East (N. Virginia and Ohio), US West (Oregon), Europe (Ireland) and Europe (Frankfurt). AWS documents that 4 base RPUs supports up to 32 TB of managed storage and recommends limiting tables to 100 columns at that size, and that 8 or 16 base RPUs supports up to 128 TB. New workgroups have AI-driven scaling enabled with a Balanced price-performance target, and you can cap spend with maximum capacity and maximum RPU-hours. You are billed while queries run, not per byte scanned.

Provisioned capacity for steady workloads

Redshift also keeps provisioned clusters. With RG and RA3 nodes you choose node count for the compute you need and pay for managed storage separately; data beyond the local SSDs is offloaded to Amazon S3 at the same storage rate. Clusters can be paused (AWS documents that only backup storage is billed while paused) and resized, and reserved nodes lower the rate for one- or three-year terms. AWS lists RG node advantages over RA3 as Graviton instances and an integrated data lake query engine.

BigQuery's equivalent of buying steady capacity is an edition commitment: Google lists 20% off for one year and 40% for three years on Enterprise and Enterprise Plus, with baseline slots. Standard edition offers autoscaling only, with no commitments, no BigQuery ML or BI Engine, and a lower service level objective (99.9% against 99.99% for Enterprise and Enterprise Plus).

Concurrency and workload isolation

BigQuery's scheduler shares slots equally between projects in a reservation and then between jobs in each project, and idle slots can be borrowed by other reservations of the same edition in the same administration project. Isolation is achieved by giving workloads separate reservations.

On a provisioned Redshift cluster, isolation is managed with workload management (WLM) queues; turning on Concurrency Scaling for a queue sends eligible queries to extra clusters when the queue is full. AWS documents support for reads and for COPY, INSERT, DELETE, UPDATE, CTAS and VACUUM on RG and RA3, one free hour of credit per 24 hours per cluster, and exclusions such as temporary tables and Python or Lambda UDFs. Separate Serverless workgroups connected by data sharing are the other way to isolate workloads.

Semi-structured data: JSON against SUPER

BigQuery's JSON type supports dot and subscript access, JSON_VALUE for scalar extraction and LAX_ conversion functions; Google lists a 500-level nesting limit and notes that JSON columns cannot be partitioned or clustered on. Redshift's SUPER type holds up to 16 MB per value and is queried with PartiQL; navigation is lax by default, so a missing attribute returns NULL.

BigQuery GoogleSQL:

SELECT JSON_VALUE(e.payload, '$.customer.id') AS customer_id,
       JSON_VALUE(item, '$.sku')             AS sku
FROM mydataset.events AS e,
     UNNEST(JSON_QUERY_ARRAY(e.payload, '$.items')) AS item;

Amazon Redshift:

SELECT e.payload.customer.id AS customer_id,
       i.sku                 AS sku
FROM events e, e.payload.items i;

SQL dialect differences

Both support QUALIFY. In Redshift, a table that is followed directly by QUALIFY must have an alias.

-- BigQuery GoogleSQL
SELECT customer_id, order_id, order_ts
FROM mydataset.orders
WHERE order_ts IS NOT NULL
QUALIFY ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY order_ts DESC) = 1;

-- Amazon Redshift
SELECT o.customer_id, o.order_id, o.order_ts
FROM orders o
QUALIFY ROW_NUMBER() OVER (PARTITION BY o.customer_id ORDER BY o.order_ts DESC) = 1;

Date functions are where ports break. BigQuery's DATE_DIFF takes the later date first and the unit last; Redshift's DATEDIFF takes the unit first and returns the second date minus the first. DATE_TRUNC argument order is reversed as well.

-- BigQuery GoogleSQL
SELECT DATE_DIFF(end_date, start_date, DAY) AS days_open,
       DATE_TRUNC(start_date, MONTH)       AS start_month
FROM mydataset.tickets;

-- Amazon Redshift
SELECT DATEDIFF(day, start_date, end_date) AS days_open,
       DATE_TRUNC('month', start_date)     AS start_month
FROM tickets;

Physical design differs too: Redshift tables carry distribution and sort keys, while BigQuery uses partitioning and clustering, which also determine how many bytes an on-demand query is billed for. Note that AWS has announced that Redshift no longer supports Python UDFs after 30 June 2026.

Sharing, lakes and multi-cloud reach

BigQuery sharing (formerly Analytics Hub) publishes listings in exchanges; subscribers get read-only linked datasets without copies, with commercial listings through Google Cloud Marketplace and support for data clean rooms. Redshift data sharing shares live data across clusters, Serverless workgroups, AWS accounts and Regions, can grant writes as well as reads, and can license data through AWS Data Exchange.

For lakes, BigQuery offers Apache Iceberg managed tables stored in your own Cloud Storage buckets, readable by engines such as Apache Spark. Redshift queries Iceberg tables catalogued in the AWS Glue Data Catalog; on RG and Serverless this runs on the warehouse's own compute with no separate charge, while RA3 and DC2 use Redshift Spectrum. Only BigQuery reaches beyond its home cloud: BigQuery Omni runs BigQuery in some AWS regions and Azure East US 2 against S3 or Blob data, but Google documents that it supports only Enterprise edition or on-demand pricing and excludes DML, JavaScript UDFs and BigQuery ML. Redshift has no equivalent for Google Cloud or Azure data.

Pricing and licensing

BigQuery. Compute is on demand, charged per TiB processed, or capacity, charged per slot-hour by edition with a one-minute minimum (per second with fluid scaling). Google's editions documentation lists commitments of one year (20% discount) and three years (40%) for Enterprise and Enterprise Plus. Storage is billed separately on logical or physical bytes, with a lower long-term rate after 90 days without modification. The Google Cloud free tier includes 1 TiB of query processing and 10 GiB of storage per month, and new Google Cloud customers receive USD 300 of credit for 90 days. We could not read the BigQuery pricing page in full, so no per-TiB or slot-hour prices are quoted; use the Google Cloud pricing calculator.

Amazon Redshift. The AWS Redshift pricing page, checked in October 2026, lists provisioned node-hours by node type (RG, RA3, previous-generation DC2) with one- and three-year reserved nodes, plus managed storage per GB-month for RG and RA3. Redshift Serverless is billed in RPU-hours per second with a 60-second minimum; AWS's pricing examples use USD 0.375 per RPU-hour in US East (N. Virginia). Redshift Spectrum (used by RA3 and DC2 for lake queries) is billed per TB scanned, and Concurrency Scaling earns one free hour per 24 hours per cluster. New Redshift Serverless users receive a USD 300 credit that expires after 90 days.

The models reward different habits: on-demand BigQuery rewards reading fewer bytes (partition filters, selecting only needed columns), while Redshift Serverless rewards keeping base capacity and run time in check. Price your actual query pattern in both calculators.

Pricing checked on the vendors' official pages on 7 October 2026. Prices change; confirm before buying.

Where each one leads

Limitations

When to choose each

When neither is right

• You need one warehouse across AWS, Azure and Google Cloud: see Snowflake vs BigQuery and Snowflake vs Redshift.
• Your work is mainly Spark, data engineering and machine learning on a lakehouse: see Databricks vs BigQuery and Databricks vs Redshift.
• Your data is modest and lives in an operational database: see BigQuery vs PostgreSQL, Redshift vs PostgreSQL and Data warehouse vs database.
• You want a broader shortlist: see BigQuery alternatives and Snowflake alternatives.

Final recommendation

Frequently asked questions

Sources

• BigQuery documentation: Understand BigQuery editions
• BigQuery documentation: Understand slots
• BigQuery documentation: Slots autoscaling
• BigQuery documentation: Storage overview
• BigQuery documentation: Estimate and control costs
• BigQuery documentation: Working with JSON data
• BigQuery documentation: Introduction to BigQuery Omni
• BigQuery documentation: Apache Iceberg managed tables
• Google Cloud free tier
• Amazon Redshift pricing
• Amazon Redshift Management Guide: Provisioned clusters and node types
• Amazon Redshift Management Guide: Serverless compute capacity
• Amazon Redshift Developer Guide: Concurrency scaling
• Amazon Redshift Developer Guide: Querying semi-structured data
• Amazon Redshift Developer Guide: Data sharing
• Amazon Redshift Developer Guide: DATEDIFF function

Checked October 2026.

How we research comparisons: our editorial method.