Amazon Redshift to Snowflake: How to Move Your Data
Move Amazon Redshift into Snowflake with Airbyte. Why source concurrency is the real constraint, choosing cursor columns, and handling a migration load.
Moving Amazon Redshift into Snowflake is usually a migration rather than an integration. Both are analytical warehouses, so there is no schema mismatch to design around and no flattening to do, which makes this one of the more forgiving pipelines in the catalogue.
What remains is a resource question. The constraint is not what Snowflake can absorb, it is what your Redshift cluster can serve while still doing its day job, because reading from it competes with the queries your analysts are running.
Amazon Redshift to Snowflake at a glance:
Why move data from Amazon Redshift to Snowflake?
Two situations account for most of these pipelines.
The first is a platform migration in progress. The organisation has chosen Snowflake and Redshift holds years of history that has to come with it, and a pipeline running alongside the old system keeps the new one current while teams move across.
The second is consolidation after an acquisition or a reorganisation, where one part of the business runs Redshift and the reporting everybody uses runs on Snowflake. Rather than teaching every dashboard to query two warehouses, you replicate one into the other.
What do you need before you start?
Most of the preparation is on the Redshift side, because that is where the cost lands:
A read-only Redshift user. With select on the schemas you intend to replicate. Create one for the pipeline rather than reusing an analyst account, so its queries are identifiable in your monitoring when you go looking for what is consuming the cluster.
A cursor column per table. The source is cursor-based, so each table needs a column that only increases and is set on every write. Warehouse tables often carry an audit column recording when a row was loaded, and that is usually the most reliable choice.
Knowledge of your Redshift workload. Specifically when the cluster is quiet and how your workload management is configured, because the sync is another concurrent query competing for the same slots as everything else.
Snowflake objects and a role. A warehouse, database, schema and a role able to create tables in that schema. Airbyte creates one table per stream with its own metadata columns alongside your data.
If either platform restricts inbound traffic by IP, add the Airbyte Cloud IP addresses to the allow list on both sides before you begin.
How do you build a Redshift to Snowflake pipeline in Airbyte?
Step 1: Find your cursors and your quiet window
Go through the tables you intend to replicate and identify a suitable cursor column on each, favouring audit columns your loading process maintains over business timestamps that may be back-dated. At the same time, find out when your Redshift cluster is least busy, because that is when this pipeline should run.
Step 2: Configure the Redshift source
Click Sources in the left navigation, then New Source, and select Redshift, following adding a source. Supply the host, port, database, schema and the read-only credentials. The connector reads over JDBC, so it appears in your cluster's query monitoring like any other client.
Step 3: Configure the Snowflake destination
Click Destinations, then New Destination, and select Snowflake, following adding a destination. Supply the account identifier, warehouse, database, schema and role with your authentication method. Sizing the Snowflake warehouse generously for the initial load and scaling it down afterwards is a reasonable approach, since the destination is rarely the bottleneck here.
Step 4: Nominate cursors and schedule off-peak
Click Connections, then New connection, select your tables, nominate a cursor field for each and choose an incremental sync mode. Schedule it after your overnight transformation jobs finish rather than during business hours, since both compete for the same Redshift resources.
Split your heaviest tables into their own connection so they do not hold up everything else, and so you can give them a different schedule if they turn out to need one.
Why is the source the constraint rather than the destination?
Because Snowflake will absorb whatever you send it, and Redshift has to produce it while also serving everybody else. A cluster has a finite number of concurrency slots, and a replication query occupying one is a slot an analyst cannot use.
That inverts the usual planning. On most pipelines you think about what the destination can take; here the useful questions are when your cluster is quiet, how your workload management queues are configured, and whether the pipeline should have its own queue with a modest allocation so it cannot crowd out interactive work.
It also means the initial migration deserves separate treatment from the ongoing sync. A full historical load is a large read, so run it during a genuinely quiet period, table by table if necessary, rather than pointing everything at the cluster at once and hoping.
What happens to deleted rows?
They stay in Snowflake, because the Redshift source is cursor-based and a query filtered on a cursor cannot observe an absence. There is no change data capture option to fall back on.
On a warehouse-to-warehouse pipeline that matters less than it would elsewhere, because warehouse tables are usually built by transformation jobs rather than edited in place. If your models rebuild tables wholesale each night, nothing is being deleted in the sense that matters, and a cursor on the load timestamp captures everything.
Where rows genuinely are removed, a periodic full refresh on those specific tables is the remedy. On a migration that is also worth doing once near cutover regardless, as a reconciliation step, so you can compare row counts between the two warehouses before anybody relies on the new one.
Frequently asked questions
Does the Redshift source support change data capture?
No. Incremental sync is cursor-based, so deletions are not captured and updates are only seen when they advance the cursor column.
Why is my sync slowing down other Redshift queries?
Because it occupies a concurrency slot like any other client. Schedule it off-peak, and consider giving it its own workload management queue with a modest allocation.
Which column should I use as the cursor?
An audit column your loading process maintains, rather than a business timestamp that might be back-dated. It needs to increase on every write.
How should I handle the initial migration load?
As a separate exercise from the ongoing sync. Run it during a quiet period, table by table if the volumes warrant it, and reconcile row counts between the warehouses afterwards.
Can I do this without writing code?
Yes. The setup above is entirely UI-driven. On a migration you will want reconciliation queries comparing the two warehouses, which is short SQL.
Get your Redshift data into Snowflake
Plan around your Redshift cluster rather than your Snowflake warehouse, because the source is what this pipeline competes with. Find reliable cursor columns, schedule after your overnight models, split heavy tables into their own connection, and reconcile row counts before anyone switches over.
Airbyte's connector catalog includes 600+ pre-built connectors, so a migration can run alongside the sources feeding both warehouses. For the same source into a lakehouse, see Amazon Redshift to Databricks, and for the reverse direction, BigQuery to Amazon Redshift.
Integrate with 700+ apps using Airbyte
Move data from 700+ sources into warehouses, lakes, and beyond. Set up pipelines in minutes with pre-built connectors and the Connector Builder.