Skip to content
All services
Solution · Redshift → Snowflake

Redshift to Snowflake. The most-asked pair, codified.

DISTKEY and SORTKEY become CLUSTER BY. WLM queues become independently-sized virtual warehouses. Spectrum tables become external stages or copy-in tables depending on access pattern. The rule library handles the bulk; the architectural decisions are named in the Discovery report.

The shape of this migration

Redshift to Snowflake is the migration pair the team has shipped most often. DDL translation, IDENTITY column continuity, SUPER → VARIANT, and Spectrum table handling are covered by the codified rule library. The harder architectural decision is the WLM-queue-to-warehouse mapping — workload-to-warehouse assignment, sizing, auto-suspend windows, and multi-cluster scaling rules. The cost economics on the target side hinge on getting this right.

What typically breaks first

  • WLM → warehouse sizing. Naive "one warehouse per old queue" leaves credits on the table. Discovery groups workloads by concurrency profile + tolerance for queue time, not by old queue boundary.
  • SUPER → VARIANT access patterns. dbt models reading SUPER columns with Redshift-specific path syntax need rewrite. The rule library generates the rewrites; the validation harness reconciles outputs.
  • IDENTITY column continuity. If app code reads next-IDENTITY values, the migration needs to carry the current high-water mark per IDENTITY column. The reconciliation report shows the continuity proof per table.
  • Spectrum read patterns. Tables read-heavy from Spectrum sometimes translate as Snowflake external tables; tables join-heavy translate to copy-in. The wrong call here costs credits later.
  • UDFs. Redshift Python UDFs (PL/Python) become Snowflake JavaScript UDFs or Python UDFs depending on Snowflake edition. SQL UDFs translate cleanly.

What you receive at each wave

  • Written inventory: every table, view, UDF, stored proc, dbt model, BI artifact, IDENTITY column, with the chosen translation path.
  • Translated DDL + DML generated from the codified rule library + bespoke handlers for the residual.
  • WLM → warehouse mapping document with sizing and auto-suspend recommendations per warehouse.
  • Reconciliation report per wave: row-count parity, schema parity, float-tolerant checksums, query-result diffs on top-50 + top-20-by-cost queries.
  • Parallel-run window: 2-4 weeks of source + target both live with daily diff reports until consumer owners sign off per-dashboard.
  • Cutover document co-signed by your platform lead + ours.

Related reading on this pair

How to start

Most engagements start with a Cloud Cost X-Ray on the Redshift side — currently free 90-min review (through Q3 2026), surfaces the top-20 waste sources and informs the warehouse-sizing model for the target. The free framing runs through Q3 2026; after that the same review reverts to a $100 5-day paid diagnostic, credited 100% to Execution if you sign within 60 days. For engagements past the diagnostic phase, book a 30-minute call for direct Discovery scoping.

Questions buyers actually ask

Before you book a call.

How does DISTKEY / SORTKEY map to Snowflake CLUSTER BY? ▾
Not 1-to-1. Snowflake uses micro-partitions with automatic clustering; the explicit CLUSTER BY directive is a hint, not a hard partition. Tables that depended on DISTKEY for join-locality on Redshift sometimes need a different column choice on Snowflake. Tables with composite SORTKEY (compound or interleaved) typically translate to a Snowflake CLUSTER BY with the leading column choice driven by query-pattern analysis. The Discovery report makes the call per table with the reasoning shown.
What about IDENTITY columns and Redshift-specific data types? ▾
Redshift IDENTITY(seed, step) becomes Snowflake AUTOINCREMENT or IDENTITY with the same semantics — but the seed/step values in production tables need to be migrated (next-value continuity). HLLSKETCH, GEOMETRY, and GEOGRAPHY data types translate cleanly. SUPER (Redshift semi-structured) maps to Snowflake VARIANT — the query syntax is different (path access notation, function names) and dbt models reading SUPER need rewrite. The rule library handles the bulk.
WLM queues vs Snowflake warehouses — how does the economic model change? ▾
Fundamentally different. Redshift WLM divides a fixed cluster across query queues; Snowflake spins up independently sized virtual warehouses per workload. The model change is the largest cost-economic decision in the migration: which workloads share a warehouse, which need their own, what auto-suspend windows fit, what size each warehouse should run at, and what multi-cluster scaling rules apply. The X-Ray-style analysis on the Redshift side is what feeds this decision — we typically run it as the first 3 days of Discovery.
What happens to Redshift Spectrum tables? ▾
Spectrum external tables (S3-backed) become Snowflake external tables or external stages depending on access pattern. If the data is read-only and queried often, an external table on S3 with Snowflake reading directly works. If the data needs frequent join performance, copy-in becomes the right call. The Discovery report enumerates each Spectrum table with the chosen path.
Do you support Redshift Serverless or only the provisioned cluster mode? ▾
Both. Redshift Serverless to Snowflake adds one wrinkle — the workload economic model on Serverless is closer to Snowflake credits than to provisioned WLM, so the warehouse-sizing decision is simpler. The rule library covers both source modes.
How is downstream BI dealt with — Looker, Tableau, Power BI, Sigma? ▾
Discovery enumerates every BI artifact and downstream consumer explicitly. For each: identify the connection profile, find the queries it issues against Redshift, regenerate against Snowflake, run parallel queries during the parallel-run window with daily diff reports. Looker LookML, Tableau .twb files, Power BI .pbix, and Sigma worksheets all get a regen pass. Reverse-ETL feeds (Hightouch, Census) need the destination model audit too.