Redshift Serverless vs Snowflake in 2026: Architecture, Concurrency, Cost Model, and Migration Friction

I have migrated in both directions. Redshift to Snowflake at a company that had outgrown a single cluster and could not stop analysts from stepping on the nightly load. Snowflake to Redshift Serverless at a smaller shop whose entire workload was one ETL window and whose Snowflake bill was mostly idle warehouses and per-second rounding. Both migrations were correct. Neither was about which engine is “better.”

The 2020 version of this comparison was easy: Snowflake had separated storage and compute, Redshift had not. That argument is dead. RA3 nodes gave Redshift managed storage, Serverless removed the cluster entirely, and concurrency scaling handles bursts. Redshift in 2026 is a genuinely different product from the one people formed opinions about.

What is left is a comparison of cost shapes, concurrency models, and how much of your organization is already inside one cloud. Those are less exciting than architecture diagrams and they are what actually determines whether you are happy in eighteen months.

If you are earlier in the decision and comparing Snowflake against the lakehouse instead, Snowflake vs Databricks is the other half of this conversation. This post assumes you want a warehouse and are choosing between the AWS-native one and the independent one.

The architectures, briefly, because they matter later

Snowflake is three layers: cloud storage holding immutable micro-partitions, a set of independent compute clusters called virtual warehouses, and a global services layer that owns metadata, transactions, security, and the query optimizer. Any warehouse can read any table. Warehouses do not know about each other. That last property is the entire product.

Redshift Serverless is a workgroup backed by a namespace. The namespace owns databases and managed storage in RMS; the workgroup owns compute, sized in Redshift Processing Units. You set a base capacity and a maximum, and AWS scales between them based on observed workload. Under the hood there are still slices, still a leader node concept, and still distribution of data across compute nodes — Serverless hides the cluster, it does not remove the shared-nothing design.

That difference shows up in one place that matters more than any benchmark: data movement on scale-up. When Snowflake resizes a warehouse, it spins up new compute that reads the same remote micro-partitions; there is nothing to redistribute. When Redshift changes capacity, the data distribution across slices has to adjust, which is why capacity changes are smoother than the old resize-and-wait but still not instantaneous.

flowchart TD
  subgraph SF["Snowflake"]
    sfs["Cloud storage: micro-partitions"]
    sfs --> w1["Warehouse: ETL"]
    sfs --> w2["Warehouse: BI"]
    sfs --> w3["Warehouse: data science"]
  end
  subgraph RS["Redshift Serverless"]
    rms["Managed storage (RMS)"]
    rms --> wg["Workgroup: base to max RPUs"]
    wg --> cs["Concurrency scaling burst"]
  end

Snowflake isolates workloads by giving each one its own compute. Redshift isolates by scaling one pool harder.

The cost model, in the units you are actually billed

Snowflake bills credits per warehouse per second, after a 60-second minimum on resume. An X-Small burns 1 credit per hour, a Small 2, a Medium 4, doubling each size up. A credit costs somewhere between roughly two and four dollars depending on edition, cloud, and region. Storage is billed separately and is cheap. The bill is therefore: sum over warehouses of size times running seconds.

Redshift Serverless bills RPU-hours, metered per second with a 60-second minimum per session of activity. Base capacity starts at 8 RPUs and moves in increments; the workgroup scales up toward your max when the optimizer thinks it needs to. Storage in RMS is billed per GB-month. The bill is therefore: RPU-seconds consumed across everything the workgroup did.

Here is the practical difference. Snowflake’s waste is idle warehouses. Redshift Serverless’s waste is over-scaling. In Snowflake, a warehouse with AUTO_SUSPEND = 600 that gets a query every nine minutes never suspends, and you pay for a full hour of nothing — I wrote a whole post on that failure mode. In Redshift Serverless, the automatic scaling will happily throw RPUs at a badly written query, and you find out at the end of the month.

The controls are correspondingly different:

-- Snowflake: cost control is warehouse configuration.
CREATE WAREHOUSE bi_wh WITH
  WAREHOUSE_SIZE      = 'SMALL'
  AUTO_SUSPEND        = 60      -- seconds. 60, not 600.
  AUTO_RESUME         = TRUE
  MIN_CLUSTER_COUNT   = 1
  MAX_CLUSTER_COUNT   = 4       -- multi-cluster for BI concurrency
  SCALING_POLICY      = 'STANDARD'
  STATEMENT_TIMEOUT_IN_SECONDS = 900;

-- Plus a resource monitor, which is the actual guardrail.
CREATE RESOURCE MONITOR bi_monitor WITH
  CREDIT_QUOTA = 500
  FREQUENCY = MONTHLY
  TRIGGERS
    ON 80 PERCENT DO NOTIFY
    ON 100 PERCENT DO SUSPEND;
ALTER WAREHOUSE bi_wh SET RESOURCE_MONITOR = bi_monitor;

{
  "comment": "Redshift Serverless: the two controls that matter.",
  "usage_limit": {
    "resourceArn": "arn:aws:redshift-serverless:us-east-1:123456789012:workgroup/analytics",
    "usageType": "serverless-compute",
    "amount": 2000,
    "period": "monthly",
    "breachAction": "deactivate"
  },
  "query_monitoring_rule": {
    "rule_name": "abort_runaway",
    "predicate": [
      { "metric_name": "query_execution_time", "operator": ">", "value": 1800 },
      { "metric_name": "scan_row_count", "operator": ">", "value": 5000000000 }
    ],
    "action": "abort"
  },
  "workgroup": {
    "baseCapacity": 32,
    "maxCapacity": 256,
    "configParameters": [
      { "parameterKey": "auto_mv", "parameterValue": "true" },
      { "parameterKey": "statement_timeout", "parameterValue": "900000" }
    ]
  }
}

I have watched teams skip both of those and then be surprised. Neither platform will protect you by default. Snowflake’s default AUTO_SUSPEND and Redshift’s default max RPUs are both set for “do not annoy the user,” not “do not spend the money.”

The crossover I keep observing: for a workload that is one predictable nightly ETL plus a modest BI layer, inside an AWS account with a Compute Savings Plan and an existing S3 lake, Redshift Serverless lands 20–40% under Snowflake. For a workload with a dozen distinct consumers, unpredictable analyst behavior, and a data science team that wants a big warehouse for two hours a week, Snowflake usually wins because the isolation prevents the over-provisioning you would otherwise buy.

Concurrency: the reason people leave Redshift

Redshift’s classic pain was one cluster serving everything. The nightly load, the dbt run, forty Tableau extracts, and one analyst with a cross join all shared the same slices and the same WLM queues. Concurrency scaling helped — it adds transient clusters for read queries — but it is bounded, it does not cover writes, and the free credit allowance runs out.

Serverless improves this materially. Scaling is automatic and faster, and you can run multiple workgroups against one namespace to give ETL and BI separate compute. But the workgroup is a heavier object than a Snowflake warehouse: you provision it, you size it, you attach networking to it. Creating one per workload team is not something you do casually.

In Snowflake, the answer to “the marketing team’s dashboards are slowing down our loads” is a CREATE WAREHOUSE statement and a role grant. Thirty seconds. That elasticity of organization, not of compute, is what people are buying when they buy Snowflake, and it is the thing that is hardest to replicate.

Concretely, the pattern I run on Snowflake:

• LOAD_WH — Medium, auto-suspend 60s, used only by the ingestion service account.
• TRANSFORM_WH — Large, auto-suspend 60s, used only by dbt.
• BI_WH — Small, multi-cluster 1 to 4, auto-suspend 60s.
• ADHOC_WH — X-Small, multi-cluster 1 to 2, with a resource monitor that suspends at quota and a statement timeout of 15 minutes.

Four warehouses, four cost centers, zero contention. On Redshift I would express this as two workgroups plus WLM queues, and I would accept that the ETL and BI workloads still influence each other when the workgroup is at its ceiling.

Performance tuning is a different job on each

This is the part migration plans underestimate.

Redshift makes you think about physical distribution. DISTKEY determines which slice a row lives on, and a join between two tables distributed on the join key is local; otherwise Redshift redistributes at query time. SORTKEY determines block ordering and enables zone-map pruning. Auto table optimization will pick these for you now and it does a decent job, but on the tables that matter you still set them yourself.

-- Redshift: physical layout is part of the DDL.
CREATE TABLE fact_orders (
  order_id      bigint       NOT NULL,
  customer_id   bigint       NOT NULL,
  order_ts      timestamptz  NOT NULL,
  status        varchar(20)  ENCODE bytedict,
  amount_cents  bigint       ENCODE az64,
  payload       super                       -- semi-structured, PartiQL
)
DISTSTYLE KEY
DISTKEY (customer_id)      -- co-locate with dim_customer
COMPOUND SORTKEY (order_ts, status);

-- Check whether the optimizer is redistributing:
-- EXPLAIN and look for DS_BCAST_INNER or DS_DIST_BOTH. Those cost money.

Snowflake makes you think about pruning and clustering depth. There are no distribution keys. Data lands in micro-partitions in insertion order, and the optimizer prunes on min/max metadata. If your access pattern does not match your insertion order, you add a clustering key and pay for automatic reclustering — the details are here, and micro-partition pruning explains why it works.

Neither is harder. They are different skills, and an engineer fluent in one is a beginner in the other for about a month. Budget that.

Migration friction, ranked by what actually hurt

1. Stored procedures and scripting. Redshift uses PL/pgSQL. Snowflake uses Snowflake Scripting, JavaScript, or Python. There is no translator worth trusting. Every procedure is a rewrite, and the ones that matter are always the undocumented ones a departed engineer wrote in 2021.

2. Distribution and sort keys have no target. Migrating Redshift DDL to Snowflake means deleting all of it, which feels great until a query that was fast because of a DISTKEY is now slow and you have to learn clustering. Going the other direction is worse: Snowflake DDL has nothing to tell Redshift about distribution, so you land with DISTSTYLE AUTO everywhere and discover the joins you never had to think about.

3. Semi-structured types. Redshift SUPER with PartiQL and Snowflake VARIANT with dot notation and LATERAL FLATTEN cover similar ground with entirely different syntax. Any table with a JSON column is a manual port.

4. Identity, not SQL. Redshift uses IAM, VPCs, and security groups. Snowflake uses its own role hierarchy, network policies, and either key-pair or SSO auth. Reproducing a permissions model across that boundary is a project of its own, and it is the one security will block the cutover on.

5. Case sensitivity and unquoted identifiers. Snowflake folds unquoted identifiers to uppercase; Redshift folds to lowercase. Every tool that quotes identifiers — most of them — will break in some small, infuriating way. Find this on day one, not in UAT.

The things that migrate cleanly: standard analytic SQL, window functions, most dbt models, Parquet in S3 (both read external tables), and BI tool semantic layers if they were built on views rather than raw tables. That last one is a good argument for always exposing a view layer, regardless of platform.

Where the lake boundary sits

Both engines can query S3 without loading. Redshift Spectrum reads external tables from the Glue Data Catalog using the same catalog Athena uses, which is a real advantage: one table definition, three engines. Snowflake reads external tables and, more usefully now, Iceberg tables with catalog integration — covered in Snowflake Iceberg tables.

My default architecture on either platform is the same: land raw data in S3 in Parquet, keep the catalog as the source of truth for what exists, and load only the modeled layers into warehouse storage. That way the warehouse decision is reversible. Every team I have seen that loaded everything into proprietary storage and deleted the lake copy has regretted it within two years, usually at renewal time.

Pitfalls

Comparing on a benchmark you did not write. Vendor benchmarks measure the query shapes that vendor is good at. Run your own top 20 queries, at your own concurrency, with your own data volume, or do not run a benchmark at all.

Migrating on price alone with no idle model. Snowflake looks expensive if you compare list credits to RPU rates. Model your actual duty cycle: how many minutes per day is compute doing useful work? Under about four hours a day, per-second billing with aggressive auto-suspend usually beats a scaled pool.

Forgetting usage limits on Redshift Serverless. There is no warehouse to forget to suspend, which lulls people into thinking there is nothing to watch. Set a monthly usage limit with a deactivate action on non-production workgroups.

Leaving AUTO_SUSPEND at the default in Snowflake. The default is generous. Sixty seconds is right for almost everything; the resume cost is a few seconds of warm cache, not a cluster boot.

Assuming concurrency scaling is free. Redshift gives one hour of concurrency scaling credit per day per cluster. A BI-heavy workload burns through that before lunch and the rest is billed.

Porting the ETL as-is. Both migrations are the one chance you get to delete the twelve tables nobody reads and the procedure that recomputes everything nightly. Take it. Lift-and-shift migrations import the technical debt at full price.

FAQ

Is Redshift Serverless just Redshift with the cluster hidden?

Largely, yes, and that is not an insult. The engine, the SQL dialect, and the distribution model are the same. What changes is that you no longer size nodes, patch, or resize, and you pay for RPU-seconds instead of node-hours. The shared-nothing architecture underneath is unchanged, which is why distribution keys still matter.

Which one is cheaper?

For a predictable ETL-plus-BI workload inside AWS, Redshift Serverless usually. For a workload with many independent consumers and spiky usage, Snowflake usually, because isolation stops you from over-provisioning a shared pool. The deciding variable is duty cycle, not the rate card.

Can I run dbt against both?

Yes, and dbt is the best migration insurance you can buy. Models written in reasonably portable SQL move with modest edits; the adapter handles the dialect differences in materializations. What does not move is anything in a macro that touches platform-specific DDL, so keep DISTKEY and clustering config in model configs rather than raw SQL.

What about Snowflake’s zero-copy clones? Does Redshift have that?

Redshift has table restore from snapshots and data sharing between namespaces, but nothing as cheap and instant as Snowflake’s zero-copy clone for spinning up a full environment copy. If your development workflow depends on cloning production every morning, that is a real point for Snowflake.

How long does a migration actually take?

For a mid-size warehouse — a few hundred tables, a few thousand dbt models, five BI dashboards that matter — plan six months of elapsed time with two engineers, running both platforms in parallel for at least two months. Anyone quoting six weeks is quoting the data copy, not the migration.

Does multi-cloud matter here?

Only if it is a real requirement rather than a slide. Snowflake runs on all three clouds and that portability is genuine. But most teams claiming multi-cloud have one cloud and a fear, and paying a portability premium for a fear is a bad trade.

What this means for your pipelines

Pick based on your duty cycle and your org chart, not on architecture diagrams. If your compute is busy a few hours a day in bursts, driven by many independent teams who all want their own answer to “why is it slow,” Snowflake’s warehouse-per-workload model is worth the premium and you will spend less time arbitrating. If your compute runs a predictable window inside an AWS account with existing commitments and a small number of consumers, Redshift Serverless is the cheaper answer and the integration with the rest of the AWS stack is real.

Whichever you choose, build the reversible version. Keep raw data in S3 in an open format, keep transformations in dbt rather than stored procedures, and expose consumers through views rather than physical tables. Do that and the warehouse becomes a compute choice you can revisit, which is the only position worth being in when a contract comes up for renewal.

The migration itself is never about SQL. It is about the four years of procedures, permissions, and quiet assumptions that grew around the old platform. Budget for that, not for the data copy, and you will be roughly right.