Move Snowflake tables into Redshift.

A less common direction, still a real one

Most warehouse-migration content online assumes the destination is Snowflake or BigQuery, because that's the direction most vendors are selling toward. Moving the other way, Snowflake into Redshift, comes up for less flashy reasons: a merger where the surviving platform is Redshift, a cost comparison a finance team actually wants real numbers for, or a workload that's cheaper on reserved Redshift capacity than on Snowflake credits. It's the same mechanical problem either direction.

Before you start

• A working Snowflake connection and a Redshift connection (IAM access key), added under Databases.
• Pipelines tier. Data Sync isn't part of Studio.
• A key column on the Snowflake side if you're doing Update or Upsert.

Steps

1. Add both connections under Databases.
2. Open Pipelines → Build and click New Sync.
3. On the left, pick the Snowflake connection and table, or write a query.
4. On the right, pick the Redshift connection and target table, or create one.
5. Drag fields across, or click AI Map.
6. Pick a MODE: Insert, Update or Upsert.
7. For Update or Upsert, choose a MATCH ON field that's unique per row.
8. Click Dry Run, then Save as a job.

A worked example

Moving a Snowflake product catalog into Redshift as part of a cost comparison test:

SELECT PRODUCT_ID, SKU, CATEGORY, PRICE_CENTS, UPDATED_AT
FROM ANALYTICS.PUBLIC.PRODUCTS
WHERE UPDATED_AT >= DATEADD(day, -1, CURRENT_TIMESTAMP());

Target analytics.products in Redshift, MODE Upsert, MATCH ON product_id. QueryFlow handles the merge into Redshift on that key, so a price change updates the existing row. Run it daily during a comparison window; a slower-moving catalog table doesn't need hourly refreshes to give a fair read on query performance and cost between the two warehouses.

A type gotcha worth knowing

Snowflake's default TIMESTAMP has no time zone attached unless you use TIMESTAMP_TZ explicitly, while Redshift's TIMESTAMP behaves the same way, no zone, and TIMESTAMPTZ is the zone-aware type. If the Snowflake source uses TIMESTAMP_TZ, map it to Redshift's TIMESTAMPTZ rather than the bare TIMESTAMP, or a stored UTC value can get silently reinterpreted as local time on read.

What this doesn't do

This doesn't carry over Snowflake-specific performance features, clustering keys, search optimization, or automatic micro-partition pruning, none of which have a Redshift equivalent that transfers automatically. If the whole point of the move is a fair cost and performance comparison, plan to set sort keys and distribution styles on the Redshift target deliberately rather than assuming an auto-created table performs the same way Snowflake did.

Running both warehouses during a cost trial

A comparison test only produces a useful answer if the same query patterns run against both sides for a comparable period, typically a few weeks of real usage rather than a single afternoon of synthetic benchmarking. Keep the sync running the whole time so the Redshift copy stays current enough that anyone testing queries against it is looking at the same data Snowflake would show them.

Picking a sync interval for this kind of migration

A cost or migration trial rarely needs sub-hourly freshness, since the goal is comparing platforms, not serving a live dashboard. Daily or twice-daily syncs are usually enough, and they keep the Snowflake compute cost of the sync itself from becoming a variable that muddies the actual comparison you're trying to run.

Documenting the comparison so it holds up later

A cost or performance trial is only as useful as the record of what was actually tested. Keep a note of which queries ran against which warehouse, at what concurrency, and over what period, separate from the sync job itself, since "Redshift felt faster" without the underlying numbers won't survive a finance review six months later when someone asks why the team is paying for two warehouses.

What a real migration adds on top of this

If the trial concludes in favor of moving fully, the sync described here becomes the backbone of the cutover, but a full migration also means moving BI tool connections, updating any scheduled jobs that reference Snowflake directly, and giving downstream teams a heads-up before their dashboards start pointing somewhere new. None of that is a Data Sync concern, but it's worth planning before calling the migration finished.

A fairer way to compare query cost between the two

Snowflake bills by warehouse size and time running; Redshift bills by cluster size and time, or by RPU-seconds on Serverless, and the two aren't directly comparable without running the same workload on each and reading the actual bill afterward. Resist the temptation to compare list prices per credit or per RPU-hour as a proxy, since the two platforms' query execution models don't map onto each other cleanly enough for that shortcut to be trustworthy.

Rebuilding downstream views, not just the table

A Snowflake-specific view using QUALIFY or a Snowflake-only function won't run unmodified against Redshift, and dashboards built on top of such a view need their own migration step separate from the raw table sync. Budget time for finding and rewriting these, since they tend to surface only when someone tries to run the equivalent report against the new warehouse and it simply fails.

Deciding who signs off on the migration being done

A warehouse migration that's technically complete, every table synced, every view rebuilt, still isn't finished until the people who actually use the data have compared a report they trust against both platforms and agreed the numbers match. Treating that comparison as a required sign-off step, not an assumption, catches the rare case where a subtle rounding or join difference between the two SQL dialects produced a number that's close but not identical.

What this costs against Fivetran

Fivetran's pricing page (September 26, 2026) meters warehouse-to-warehouse connectors the same way as any other source: 500,000 MAR free, then a $5 base charge per connection between 1 and 1,000,000 MAR, with usage pricing beyond that behind a quote. QueryFlow Pipelines is $199.99 a year flat, which matters more for a trial migration than a permanent one, since there's no ongoing per-row cost to factor into whichever platform wins the comparison.

Comparison

Check it worked

Run Dry Run and spot-check against Snowflake. After a real run, compare row counts on both sides and check the job's history for any listed errors.

Troubleshooting

Sources

• Fivetran Pricing — accessed September 26, 2026
• QueryFlow on the Mac App Store — accessed September 26, 2026