Every Redshift estate we look at in 2026 is asking the same question: should this be a provisioned RA3 cluster or a Serverless workgroup? The honest answer is that it depends on the shape of the workload, and the shape is measurable. This is the framework we use.
The two pricing models in one paragraph
A provisioned RA3 cluster is billed per node-hour whether or not anything is running, plus Redshift Managed Storage (RMS) per GB-month. You choose the node type and count, you can buy reserved nodes for one or three years at a substantial discount, and you add Concurrency Scaling clusters (billed per second, with a free daily allowance) when queues build.
A Serverless workgroup is billed per RPU-hour (Redshift Processing Units, in 8-RPU increments, billed per second with a 60-second minimum per query burst) only while queries run, plus the same RMS storage. You set a base capacity and a maximum, and there is nothing to reserve. Current rates for both are on the Amazon Redshift pricing page and vary by region.
The workload-shape quadrant
Plot your warehouse on two axes: utilization (how many hours a day compute is genuinely busy) and predictability (how much the busy hours vary day to day).
| Predictable | Unpredictable | |
|---|---|---|
| High utilization (16+ busy hours/day) | Provisioned RA3 with reserved nodes. Nothing beats it per hour. | Provisioned RA3 plus Concurrency Scaling; or a hybrid with Serverless consumers via data sharing. |
| Low utilization (under 8 busy hours/day) | Serverless. Pay for the busy hours, scale to zero otherwise. | Serverless. This is the case it was built for. |
The middle band, 8 to 16 busy hours with moderate variance, is where you need the arithmetic.
The break-even arithmetic
Take your current cluster's node-hours per month and multiply by the RA3 on-demand (or reserved) rate: that is the provisioned cost. Then estimate Serverless cost as:
RPU-hours per month = busy hours per month x average RPUs while busy
Serverless cost = RPU-hours x regional RPU-hour rate
"Average RPUs while busy" is the part people guess wrong. A workload that needed a 4-node ra3.4xlarge cluster does not need 128 RPUs all day; it needs whatever capacity keeps query latency acceptable during its busy windows, which you discover by running a Serverless workgroup against a restored snapshot with base capacity set low and measuring. For most BI-shaped workloads the effective RPU usage is well below the cluster's nominal equivalent.
Worked example, rounded. A 4-node ra3.4xlarge on-demand cluster runs about 2,900 node-hours a month. Suppose its real work is 6 busy hours a day at an average of 32 RPUs: that is about 5,800 RPU-hours a month. Put each number against your region's rates and the Serverless figure is usually a fraction of the on-demand provisioned figure. Now put a three-year reserved rate on the cluster and run the same comparison: the gap narrows considerably, and at 14 or more busy hours a day it flips.
Three corrections to apply before you believe the number:
- Concurrency Scaling charges you are paying today disappear on Serverless (it scales within the max RPU instead). Add them to the provisioned side.
- Always-on ingestion (zero-ETL integrations, streaming views with auto refresh) keeps a Serverless workgroup busy. Count those hours as busy.
- The 60-second minimum per query burst penalizes workloads made of thousands of tiny, sparse queries. Look at
SYS_QUERY_HISTORYfor query count per hour, not just total seconds.
The reserved-instance angle
Reserved RA3 nodes are the strongest argument for staying provisioned. If you already hold a three-year reservation, moving to Serverless before it expires means paying twice. If you are about to renew, the decision has a hard deadline and the analysis above is worth doing properly before you sign.
Serverless has no reservation, which is also a feature: a team that cannot forecast next year's usage is not locked in.
Hybrid: the answer for most organizations
The pattern we deploy most often is neither/nor. A provisioned RA3 cluster (reserved) handles the 24/7 ingestion and transformation load as a producer. BI tools, analysts and each business unit get their own Serverless consumer workgroup reading the producer's tables through data sharing. The steady load gets the reserved discount; the spiky load pays only when it runs; each consumer's cost is attributable to its team. See Redshift Data Sharing Across Accounts for the mechanics.
Migration effort
Provisioned to Serverless is a snapshot restore into a new namespace, so the data move is minutes to hours. The real effort:
- Endpoint changes in every BI tool, ETL job and application connection string
- WLM queue configuration has no equivalent; query priorities and monitoring rules carry over in different form
- Maintenance scripts that assume a cluster (resize, pause/resume schedules) are removed
- IAM roles, VPC security groups and KMS keys reattached to the namespace and workgroup
- A parallel-run period comparing real Serverless spend to the model
Budget two to four weeks for a typical estate, most of it on the connection inventory rather than the database.
Serverless to provisioned is the same snapshot path in reverse, and worth remembering: the decision is not one-way.
The short version
- Under 8 busy hours a day: Serverless.
- Over 16 busy hours, predictable: provisioned RA3, reserved.
- In between, or mixed: measure, then usually hybrid with data sharing.
If you want the measurement done for you, with the model in a spreadsheet you keep, that is our Redshift Serverless Migration & Right-Sizing service.