Redshift to Snowflake migration that moves Redshift tables into Snowflake in parallel
The Redshift to Snowflake migration from Adapters copies Redshift tables into Snowflake on an incremental schedule, mapping Redshift types to Snowflake types and merging on the key, so both warehouses run in parallel and you cut over once the row counts and totals agree. Field mapping is no-code, so try it against sample records in the live demo.
The live demo needs no card, and Starter is $49 a month.
Field mapping auto-plugged · tap a port to rewire
Plug a source port into
Transform on this cable
JSON in
JSON out
5 sample records ready
What running Redshift to Snowflake by hand costs you
- A big-bang UNLOAD and COPY migration means a frozen reporting window, and the business rarely agrees to one.
- Redshift folds unquoted identifiers to lowercase and Snowflake folds them to uppercase, so a naive copy breaks every downstream query that quoted a name.
- Redshift SUPER columns, distribution keys, and sort keys have no direct Snowflake equivalent, so teams either lose semantics or over-engineer the target schema.
The field mapping, out of the box
All 6 of these Redshift to Snowflake fields arrive mapped. Rewire any of them, or add your own, in the same visual data mapping tool you use for every adapter.
Input / REDSHIFT
Output / SNOWFLAKE
Transforms included
Incremental runs use a Redshift watermark column so only changed rows move; DECIMAL keeps its precision as Snowflake NUMBER, VARCHAR byte-length limits widen to Snowflake VARCHAR without truncation, SUPER columns land as VARIANT, TIMESTAMP and TIMESTAMPTZ normalize to TIMESTAMP_TZ in UTC, lowercase Redshift identifiers fold to Snowflake uppercase consistently so quoted references keep working, distribution and sort keys are dropped in favor of Snowflake clustering where it earns its cost, and loads MERGE on the primary key so a replayed batch updates in place.
Redshift to Snowflake type mapping, the identifier case flip and proof the migration landed correctly
Moving a warehouse is not a data transfer project, it is a correctness project. The rows almost always arrive. What breaks is the handful of types that do not have a clean counterpart, identifiers that change case in opposite directions on the two platforms, and the absence of any check that proves the new warehouse agrees with the old one. AWS and Snowflake documentation read 19 August 2026.
Identifier case flips in the opposite direction on each platform
This is the first thing that breaks and the least expected. Redshift folds unquoted identifiers to lowercase. Snowflake folds them to UPPERCASE. So a table that has always been orders in Redshift becomes ORDERS in Snowflake, and any BI tool, script or dbt model that quoted the lowercase name now fails to resolve it. Decide the convention once, at the start: either let everything fold naturally and never quote, or quote consistently everywhere. Mixing the two produces a warehouse where two spellings of the same table appear to exist.
The types that need an explicit decision
Redshift VARCHAR is measured in bytes and caps at 65,535. Snowflake VARCHAR is measured in characters, defaults to 16 MB and maxes at 128 MB, so the destination is roomier and the risk runs the other way: a column that was tightly sized in Redshift for a reason lands unbounded in Snowflake and nobody notices when garbage starts fitting. Numerics need the same care. Snowflake NUMBER defaults to precision 38, scale 0, which silently truncates the cents off any money column that lands on the default. Set NUMBER(18,2) explicitly. Timestamps are the third: Redshift TIMESTAMP has no zone and Snowflake TIMESTAMP_NTZ matches it, but TIMESTAMPTZ should map to TIMESTAMP_TZ rather than being flattened.
Distribution and sort keys have no counterpart, and that is fine
Redshift performance work lives in DISTKEY, SORTKEY and ENCODE. None of them exist in Snowflake, which manages micro-partitions itself. Teams migrating often try to reproduce the tuning and end up with cluster keys they do not need on tables far too small to justify them. The honest advice is to migrate the schema without the physical tuning, measure real query performance, and only then add clustering to the few large tables that demonstrably need it. Carrying over a decade of Redshift-specific tuning is work that mostly produces cost.
The staging path, and the file sizes each side wants
The workable route is UNLOAD from Redshift to S3, then COPY INTO from an external stage in Snowflake, with Parquet preferred over CSV because it carries types and compresses well. Match the file sizing to Snowflake rather than to Redshift: Snowflake recommends 100 to 250 MB compressed per file and does not recommend files of 100 GB or more, and the default COPY timeout is 24 hours. Redshift UNLOAD will happily produce whatever the MAXFILESIZE setting says, so set it deliberately instead of accepting one enormous file per slice.
Prove it landed, with three checks rather than a row count
A matching row count is the weakest possible evidence, because it survives every type and encoding error there is. Run three checks per migrated table instead. Count, to catch a partial load. Checksum of the sum of every numeric column, which catches truncated scale, minor-unit errors and NULL handling differences. And a spot comparison of the extreme rows: the longest text value, the oldest and newest timestamps, and the largest and smallest numeric. Those three together catch nearly everything that a count alone hides, and they take a morning to write against a warehouse you are going to trust for years.
How Adapters handles this lane, and where it does not fit
Adapters runs the scheduled movement with explicit type mapping, consistent identifier casing and per-record error logs, at a flat $49 to $399 a month, which suits an ongoing sync or a migration you want to run repeatedly until the cutover. It is not a lift-and-shift migration service: if the job is a one-time move of hundreds of terabytes with schema conversion of stored procedures and views, that is a project, not a connector, and a specialist migration tool or AWS SCT plus a partner will serve you better. If you are staying on AWS and only need operational data in Redshift, compare the cost of Redshift zero-ETL integrations first. For the wider destination comparison, see Snowflake ETL tools.
How it goes live
Moving Redshift data into Snowflake on flat data integration pricing from $49 a month.
STEP 01
Pick the pair
Authorize a read scope on Redshift and a write scope on Snowflake, nothing wider.
STEP 02
Confirm the mapping
Check that orders.id lands in ORDERS.ID and orders.status in ORDERS.STATUS on a sample record.
STEP 03
Schedule the sync
Turn on the REDSHIFT → SNOWFLAKE schedule; failed records retry and every run is logged.
Redshift to Snowflake sync common questions
How do I migrate from Redshift to Snowflake?
UNLOAD each Redshift table to S3 as Parquet, COPY it into Snowflake, then run both warehouses in parallel while you port queries and dashboards. Migrating one reporting domain at a time keeps a working system in place throughout and lets you compare totals across two live systems instead of trusting a single cutover weekend.
What are the biggest Redshift to Snowflake migration challenges?
Physical tuning, identifier case and SUPER columns. Distribution keys and sort keys have no Snowflake equivalent, so that tuning work is discarded rather than translated, and teams often over-engineer clustering keys trying to replace it. Redshift folds unquoted identifiers to lowercase while Snowflake folds them to uppercase, which breaks any query that quoted names. SUPER columns become VARIANT and the access syntax changes.
How do Redshift types map to Snowflake?
SMALLINT, INTEGER and BIGINT all become NUMBER(38,0), DECIMAL becomes NUMBER with the same precision and scale, REAL and DOUBLE PRECISION become FLOAT, and BOOLEAN stays BOOLEAN. VARCHAR becomes VARCHAR, and the byte-length limit disappears because Snowflake VARCHAR defaults to 16,777,216 bytes. TIMESTAMP becomes TIMESTAMP_NTZ, TIMESTAMPTZ becomes TIMESTAMP_TZ, and SUPER becomes VARIANT.
Do dist keys and sort keys transfer to Snowflake?
No, and you should not try to recreate them. Snowflake stores data in micro-partitions and prunes automatically on the natural load order, so most tables need no manual physical design at all. Add a clustering key only after a specific large table demonstrably scans too much, not as part of the migration.
How does the Redshift to Snowflake sync work?
The Redshift to Snowflake migration from Adapters copies Redshift tables into Snowflake on an incremental schedule, mapping Redshift types to Snowflake types and merging on the key, so both warehouses run in parallel and you cut over once the row counts and totals agree. Field mapping is no-code, so try it against sample records in the live demo.
How much does the Redshift Snowflake integration cost?
The Redshift to Snowflake pair is included on every plan: Starter $49, Growth $149, Scale $399 a month. You pay per plan, not per row or task, so a busier month costs the same.
Do I need to write code to connect Redshift and Snowflake?
No. Fields are auto-mapped the moment you pick the pair, and you can rewire any mapping visually before the first sync. Incremental runs use a Redshift watermark column so only changed rows move; DECIMAL keeps its precision as Snowflake NUMBER, VARCHAR byte-length limits widen to Snowflake VARCHAR without truncation, SUPER columns land as VARIANT, TIMESTAMP and TIMESTAMPTZ normalize to TIMESTAMP_TZ in UTC, lowercase Redshift identifiers fold to Snowflake uppercase consistently so quoted references keep working, distribution and sort keys are dropped in favor of Snowflake clustering where it earns its cost, and loads MERGE on the primary key so a replayed batch updates in place.
Related Redshift and Snowflake connectors
Browse the full api connector library, or request a pair you do not see.
Redshift and Snowflake, finally in agreement
Map the pair once and let it sync on schedule. Flat price from $49 a month, no per-task fees.
The live demo needs no card, and Starter is $49 a month.