How would you choose between Redshift Serverless and a provisioned RA3 cluster for a new analytics platform?

## The two deployment models Amazon Redshift ships in two shapes. A **provisioned cluster** is the classic one: you choose an RA3 node type and node count, you get a leader node and compute nodes, and you pay for node hours whether or not queries run. **Redshift Serverless** removes the cluster from your vocabulary: you create a **namespace** and a **workgroup**, and Redshift supplies compute on demand. - The **namespace** is the database side of the split: schemas and tables, users and permissions, snapshots, and the managed storage that holds the data. - The **workgroup** is the compute side: a base capacity expressed in **RPUs** (Redshift Processing Units), the VPC subnets and security groups, the endpoint clients connect to, and any usage limits you set. One namespace can have several workgroups attached, which is the natural way to give different teams isolated compute over one copy of the data. ## Billing shape is the core difference Provisioned compute is billed by node-hour: the meter runs continuously, and reserved-instance commitments discount it substantially in exchange for a term. Serverless compute is billed by RPU-second consumed while queries run, with a short minimum charge per session, so an idle warehouse costs (almost) nothing on the compute axis. Storage is billed by the gigabyte in both models, because both sit on Redshift Managed Storage. That makes the choice largely arithmetic once you know your **duty cycle**. A warehouse whose compute is genuinely busy most of the day is usually cheaper as a committed provisioned cluster. A warehouse that runs an ETL burst at 3am and serves a handful of analysts between 9 and 5 is a poor fit for a meter that never stops. Do not guess: on an existing cluster you can measure utilization directly, and on serverless the usage view (`SYS_SERVERLESS_USAGE`) reports what capacity was actually consumed. ## Control, and what you give up Provisioned gives you knobs: exact node count and type, resize scheduling, and hands-on workload management. Serverless deliberately hides those. You set a **base capacity** floor — which raises or lowers the amount of compute a given query starts with, and is the main performance dial you have — and Redshift scales beyond it as demand requires. Cost governance moves from "choose a smaller cluster" to setting **usage limits** on RPU-hours with actions such as alerting or stopping queries when a threshold is crossed. Newer releases add price-performance-oriented automatic scaling, so verify what is available in your region and version before designing around a specific control. For a team that has invested years in tuned workload management on a provisioned cluster, giving that up is a real cost. For a team that has never tuned it, having fewer knobs is a feature. ## Isolation and the hybrid pattern The two models are not a fork in the road. Data sharing lets a serverless workgroup read a provisioned cluster's data live, and vice versa, without copying it — both sides sit on managed storage. That enables the pattern most large platforms converge on: - a **provisioned RA3 cluster** as the always-on core running ingestion and scheduled transformation, sized and committed for that steady load; - **serverless workgroups** for ad-hoc analysis, data science, and bursty consumer teams, each isolated so a runaway exploratory query cannot disturb the pipelines; - one copy of the data underneath. Billing attribution improves too: each consumer workgroup's RPU-seconds are that team's cost. ## How to run the decision 1. **Characterize the workload.** Hours per day with meaningful compute demand; peak-to-average ratio; how predictable next quarter looks. 2. **Decide whether the commitment is safe.** Reserved pricing is only a saving if the shape you commit to is the shape you still want in a year. New platforms rarely know that. 3. **Weigh operational maturity.** Do you have someone who will actually tune workload management? If not, the provisioned control surface is a liability rather than an advantage. 4. **Design isolation deliberately.** Whichever you pick, decide up front how ad-hoc users are kept away from pipeline SLAs — separate workgroups or separate clusters over shared data, rather than one shared pool and hope. 5. **Instrument and revisit.** Measure consumption for a quarter and move. Migration between the models is a snapshot restore or a shared-data cutover, not a rewrite. ## What a strong answer sounds like A principal-level answer refuses the false binary. It names duty cycle as the cost driver, distinguishes namespace from workgroup, acknowledges the loss of manual workload control on serverless, and lands on a hybrid with explicit isolation and cost-attribution reasoning rather than declaring one product better.