Sync tables from Redshift into Snowflake.

Why teams move off Redshift, in stages

A full Redshift-to-Snowflake migration is a project, not a sync, and this page isn't that. What comes up more often is smaller: a team is evaluating Snowflake, or has already committed to it, and needs specific tables mirrored over while the two systems run side by side for a while. That's a sync problem with a migration flavor, not a one-time cutover.

Before you start

• A Redshift connection and a Snowflake connection, both added under Databases.
• Pipelines tier. Data Sync isn't part of Studio.
• A clear list of which tables are moving first; migrating everything at once tends to hide problems rather than surface them early.

Steps

1. Add your Redshift connection under Databases if you haven't already.
2. Add your Snowflake connection: account identifier, warehouse, and a Programmatic Access Token.
3. Open Pipelines → Build and click New Sync.
4. On the left, pick Redshift as your source and write the query for the table or rows you're moving.
5. On the right, pick your Snowflake connection and the target table, or create one.
6. Drag columns across, or click AI Map to pair them by name.
7. Pick a MODE: Insert for a first load, Update or Upsert for an ongoing refresh.
8. For Update or Upsert, set a MATCH ON field, a unique key column.
9. Click Dry Run, check the preview, then Save or run it now.

A worked example

Moving a customers dimension table over first, since dashboards elsewhere will need it as soon as fact tables start landing in Snowflake too:

-- Redshift source
SELECT customer_id, company_name, region, signed_up_at
FROM analytics.customers;

-- Snowflake target
CREATE TABLE IF NOT EXISTS ANALYTICS.PUBLIC.CUSTOMERS (
  CUSTOMER_ID NUMBER,
  COMPANY_NAME VARCHAR,
  REGION VARCHAR,
  SIGNED_UP_AT TIMESTAMP_NTZ
);

Run this once as Insert for the initial load, then switch the same sync to Upsert with MATCH ON set to CUSTOMER_ID for ongoing runs, so new customers get added and existing ones stay current while both systems are live.

Check it worked

Compare row counts on both sides after each run, and spot-check a handful of customer IDs directly rather than trusting an aggregate count alone, since a count can match even if a few individual rows landed with the wrong values.

SELECT COUNT(*) AS row_count FROM ANALYTICS.PUBLIC.CUSTOMERS;

Troubleshooting

A note on the migration itself

Data Sync moves rows. It doesn't carry over Redshift-specific objects like stored procedures, WLM queue configuration, or user grants, and connections themselves have to be re-added by hand rather than imported wholesale. Treat this as the table-by-table mechanism inside a bigger migration plan, not the entire plan.

A second worked example: a large fact table with Upsert

Dimension tables like customers are small and cheap to move in full every run. A fact table with years of order history is a different problem, moving all of it every time wastes both time and Snowflake compute. Filter the source to a recent window and let Upsert handle both new and changed rows:

-- Redshift source
SELECT order_id, customer_id, order_total, status, updated_at
FROM analytics.orders
WHERE updated_at >= GETDATE() - INTERVAL '7 days';

A 7-day window is usually enough to catch late-arriving updates without re-scanning the entire table's history on every run. If your source system occasionally corrects an order from months back, widen the window periodically, or run a one-time full sync alongside the regular incremental one, rather than assuming a week always covers every edit.

Performance on a large historical backfill

The very first load of a multi-year fact table is the slowest step in the whole process, and it's worth doing separately from the ongoing incremental syncs rather than as the same job. Run the full historical load once, unfiltered, as a dedicated Insert sync, confirm the row count lines up, and only then switch to the smaller windowed Upsert sync for everything going forward. Trying to do both in one sync tends to make the first run painfully slow while adding complexity the ongoing runs don't need.

Related syncs

See also: Integrations Sync BigQuery to Snowflake CSV to Snowflake on Mac.