How to Migrate from Redshift to BigQuery in 2026

Moving a warehouse from Amazon Redshift to Google BigQuery is three separate jobs: copy the data, translate the SQL, and rebuild the pipelines that feed the warehouse. No single tool does all three well, so the honest answer to "which tool should we use" depends on which job you are looking at. This guide covers the documented options for each one, with setup requirements, limits, and prices.

Which tool should we use to migrate from Redshift to BigQuery?

Google's BigQuery Data Transfer Service handles the move itself. It copies both schema and data from a Redshift cluster into BigQuery, and Google charges nothing for it. A replication tool like Airbyte helps when you need Redshift and BigQuery updated in parallel during a dual-run period.

That covers the data. For the SQL, Google's BigQuery Migration Service includes batch and interactive translators that convert Redshift SQL into GoogleSQL, also at no charge.

The third job is easy to miss: every pipeline that loaded data into Redshift needs a new home. An ELT platform like Erathos moves data from your sources into BigQuery with batch, cursor-based incremental, or change data capture (CDC) pipelines, so you can rebuild ingestion without writing new pipeline code.

How does Google's Redshift transfer service work?

The BigQuery Data Transfer Service runs migration agents that trigger an unload from your Redshift cluster into an Amazon S3 staging bucket, then load that staged data into BigQuery. You bring the S3 bucket, a JDBC connection string, database credentials, and AWS access keys with read rights on the bucket.

Your Redshift cluster also has to accept connections from Google. For a public cluster, that means allowlisting Google's migration IP ranges on the cluster port, which is 5439 by default. For a private cluster, Google has a VPC route: you connect your Google Cloud and AWS networks with a VPN, reserve an IP range with more than 10 addresses, and Google peers a tenant project into your network. The VPC path allows at most 5 concurrent transfer runs, and a Shared VPC network does not work.

Two limits matter for large warehouses. BigQuery loads at most 15 TB per load job per table, so a single wider table needs splitting. And because of the way S3 lists objects, some staged files can be left out of a transfer, so comparing row counts after each run catches missing data. Google also suggests a 24-hour lifecycle rule on the staging bucket, so the rule deletes leftover files automatically.

Which tool fits a one-time move, a dual run, or the long-term stack?

A one-time move fits the Data Transfer Service. A dual run needs a replication tool with a documented Redshift source, and Airbyte is the one whose docs spell that out. The long-term ingestion stack is a separate purchase, and that is where managed ELT platforms compete.

Airbyte's Redshift source runs incremental syncs by ordering on a cursor column you define, such as an updated_at timestamp. Rows deleted in Redshift stay in BigQuery, so a dual run that includes deletes needs full refreshes or a soft-delete column on the Redshift side.

What will not move automatically from Redshift to BigQuery?

The Data Transfer Service moves tables. Queries, views, stored procedures, user-defined functions, and physical table design all need translation work, and some of it is manual.

Most data types map one to one, but two timestamp mappings change the type's meaning:

SQL differences break silently. In Redshift, the caret operator means exponent; in BigQuery it means bitwise xor, so a query can return wrong numbers without any error. Ascending sorts put NULL values last in Redshift and first in BigQuery, which flips the top row of many reports. Most implicit type conversions that Redshift accepts must become explicit casts. And BigQuery has no SQL COPY command, so you replace any COPY-based load script with load jobs.

Functions written in SQL translate. Redshift also supports Python user-defined functions, while BigQuery supports JavaScript ones, and the batch translator only translates SQL UDFs. You rewrite Python UDFs by hand. Table constraints like PRIMARY KEY and FOREIGN KEY do not exist as enforced constraints in BigQuery, and distribution keys go away entirely because BigQuery distributes data during query execution. Compound sort keys usually become clustering.

How should we validate and cut over?

A staged cutover works well, with the SQL translation report as the gate between stages. The batch SQL translator takes your Redshift SQL files from Cloud Storage and writes back translated files plus a CSV summary listing every warning and error, so you know exactly how much manual rewrite work is left before you commit to a date.

A staged plan that follows the documented tooling:

1. Scope the first transfer with the Data Transfer Service's table name patterns, starting with one schema.
2. Run the transfer and compare row counts between Redshift and BigQuery.
3. Batch-translate your queries, views, and SQL UDFs, then work through the CSV summary.
4. Run the translated queries against the migrated data and diff results against Redshift, paying attention to NULL ordering and timestamp columns.
5. Dual-run both warehouses while dashboards and downstream jobs move over, using scheduled transfer runs or a replication tool to keep BigQuery current.
6. Point ingestion pipelines at BigQuery, then shut the Redshift cluster down.

How much does a Redshift to BigQuery migration cost?

The migration tooling itself is free: Google charges nothing for the Migration API, the SQL translators, or the Data Transfer Service runs from Redshift. What you pay for is everything around it: the Redshift cluster staying up during the dual run, S3 storage and requests for the staging bucket, Cloud Storage for translation input and output files, and BigQuery storage once the data lands.

Third-party costs only enter if you add a replication bridge or a managed ELT platform. Fivetran bills by monthly active rows with a $5 base charge on small connections, and skips billing on the initial bulk load. Erathos bills by rows written to the warehouse per month, with a free plan up to 1M rows and CDC starting on the US$ 250/mo Pro plan.

Fivetran's plan cards, priced by monthly active rows

Erathos pricing plans, billed by rows written to the warehouse per month

What feeds BigQuery after the migration?

The transfer service gets your history into BigQuery once. From then on, every source that loaded into Redshift needs a pipeline into BigQuery instead, and that ongoing layer is where a managed ELT platform earns its place.

Erathos has over 100 connectors. It stages extracted data in temporary cloud storage, then loads it into the warehouse and deletes the temporary files. Plans are flat monthly prices by row volume, so you know the cost of the new ingestion stack before the migration starts, and the BigQuery integration is free to test for 14 days.

Rebuild your ingestion layer without writing new pipelines

The transfer service and SQL translators only run once. Erathos is what replaces the pipelines that used to feed Redshift — over 100 connectors, batch or CDC, flat monthly pricing by row volume, and free up to 1 million rows a month. Try Erathos free for 14 days.