AMAZON REDSHIFT → SNOWFLAKE
Move Amazon Redshift tables into Snowflake without turning the migration into a one-off export project.
Supaflow gives your Redshift-to-Snowflake migration a repeatable workflow: connect Redshift, choose tables from the schemas your user can access, load them into Snowflake, and monitor every run with object-level status and row counts. Start with a full first load, then keep Snowflake updated while validation and cutover are still in progress. Every connector is included on every Supaflow plan — you pay only for the compute your pipelines consume.
Used by data teams consolidating Redshift warehouses into Snowflake, validating row counts before cutover, and keeping Redshift data available during phased migrations — with no per-row fees.
Need the full setup sequence? Read the step-by-step Amazon Redshift to Snowflake guide.
Every row below is an actual capability in the Amazon Redshift connector, not a forward-looking promise.
| Feature | How it works | Limit / caveat |
|---|---|---|
| Accessible schema coverage | Supaflow discovers Redshift tables across every schema the configured database user can access. Select the exact schemas, tables, and columns you want to move into Snowflake. | Grant the Redshift user USAGE on each schema and SELECT on each table you want available in the pipeline. |
| Full first load | Run an initial load to create the destination tables in Snowflake and copy the selected Redshift data into the Snowflake project destination. | Run time depends on table size, Redshift capacity, Snowflake warehouse size, and the number of objects selected. |
| Ongoing updates | After the first load, Supaflow can keep Snowflake updated for tables that expose a reliable updated-at timestamp, increasing ID, or similar change marker. | This is not log-based CDC. Hard deletes are not captured unless your source tables model deletes explicitly. |
| Cutover-ready load behavior | Use merge mode to keep Snowflake tables updated with new and changed rows, or choose the load behavior that matches your migration and reporting workflow. | — |
| Schema evolution | When Redshift columns change, Supaflow applies compatible schema changes in Snowflake according to the schema evolution setting you choose for the pipeline. | — |
| Run monitoring | Every run shows pipeline status, object-level progress, row counts, duration, and table-specific errors so you can validate the migration before cutover. | — |
| Deployment options | Use Supaflow managed infrastructure or run the sync agent in your own VPC when Redshift access needs to stay inside your network. | — |
Every Supaflow connector is included on every plan at no extra cost. You pay only for compute consumed, measured in Supaflow Credits (1 credit = 1 compute-hour on a Small node). No per-row fees.
One-off exports help with the first copy, then immediately start drifting. Supaflow gives you a pipeline you can run once for migration, repeat during validation, and schedule after cutover if Snowflake needs to stay current.
Redshift-to-Snowflake projects usually succeed or fail on validation: which tables moved, how many rows loaded, which objects failed, and what needs a rerun. Supaflow puts that status in the Jobs tab instead of leaving it buried in scripts and logs.
Every one of these is something our connector handles specifically. A generic pipeline built in Airflow or a basic ELT tool will hit at least three of them in production.
Failure mode: A manual export may be accurate when it starts, but production Redshift tables can change before the Snowflake cutover finishes.
Evidence: Common migration pattern when teams copy tables once, validate for several days, and then discover the source has moved on.
Fix: Supaflow lets you run the full first sync, validate, and then rerun or schedule incremental updates while the migration is still in progress.
Failure mode: Some Redshift tables do not have an updated-at timestamp, increasing ID, or other column that safely represents changed rows.
Evidence: Common in analytics warehouses where modeled tables are rebuilt, appended, or overwritten by upstream jobs.
Fix: Use incremental sync where a reliable update marker exists, and full refresh for smaller tables or tables where the source does not expose one.
Failure mode: If a row disappears from a Redshift table, a later sync cannot query that missing row on the next run.
Evidence: Standard limitation for warehouse replication that reads the current table state.
Fix: Model deletes explicitly in Redshift when downstream consumers need delete awareness, or handle cleanup in Snowflake after validation.
Failure mode: A table that was not granted to the migration user will not be available when the team is choosing objects to sync.
Evidence: Typical least-privilege setup issue during warehouse migrations.
Fix: Grant schema USAGE and table SELECT before discovery, then refresh schema in Supaflow so the object list reflects the current Redshift grants.
Provide the Redshift endpoint, database, and credentials for a user with read access to the schemas and tables you want to migrate.
Redshift source docs→Create or choose the Snowflake destination where the migrated Redshift tables should be created.
Snowflake destination docs→Select the Redshift tables and columns to move. Run a full first load, then use incremental sync for tables with a reliable update marker.
Trigger the first sync, review job status and row counts, fix any object-level errors, and compare Snowflake counts before cutover.
Step-by-step tutorial→Supaflow connects to Redshift, discovers tables the configured user can read, and loads the selected tables into Snowflake. The first run can load historical data, and later runs can keep Snowflake updated for tables with a reliable updated-at timestamp, increasing ID, or similar change marker.
The Redshift source is built for tables across the schemas your database user can access. Grant USAGE on the schema and SELECT on each table you want to include, then refresh schema in Supaflow if grants change.
Yes. You can schedule the pipeline after the first load. Tables with reliable update markers can run incrementally, while smaller or rebuilt tables can run as full refreshes.
No. Redshift-to-Snowflake sync is not log-based CDC. It can sync new and changed rows when a reliable update marker exists, but it does not detect hard deletes unless your source tables model deletes explicitly.
The setup can be completed in about 30 minutes once Redshift and Snowflake permissions are ready. The first data load depends on table size, warehouse capacity, selected objects, and Snowflake warehouse size.
Fivetran and Hevo often price by rows or changed-record volume, so a large historical migration can turn into a large bill. Every Supaflow connector is included on every plan at no extra cost. You pay only for compute consumed, measured in Supaflow Credits (1 credit = 1 compute-hour on a Small node). No per-row fees. See the pricing page for the credit packages and free tier.
Yes. The sync agent can run in your own VPC when Redshift access, credentials, and data movement need to stay inside your network. The control plane is managed; the data plane can be managed or self-hosted.
The Amazon Redshift source and Snowflake destination, plus other Supaflow connectors you can pair into a Snowflake pipeline.
Source and destination connector overview and capabilities.
Destination connector overview and capabilities.
For Postgres-side replication into Snowflake.
For Microsoft-side replication with Change Tracking and hard-delete capture.
For file-based migrations from CSV, TSV, Excel, and Google Sheets.
Browse the full catalog of sources and destinations.
A practical walkthrough for setting up Redshift, Snowflake, the pipeline wizard, the first sync, and validation.
Connection setup, permissions, object selection, incremental configuration, and troubleshooting.
Connect your Snowflake warehouse, role requirements, advanced settings, and sync behavior.
Every connector is included on every plan. Pay only for compute consumed (Supaflow Credits).
Every connector is included on every Supaflow plan — you pay only for the compute your pipelines consume. Full first load, ongoing updates where your tables support them, row-count visibility, and scheduled runs after cutover.