Pro · Lesson 3 of 9
Leader, compute slices, and managed storage are the three pieces. Serverless hides the nodes and keeps the same shape.
Sign in to save your place.
The leader node is the head waiter. It hears your SQL, plans the work, and sends pieces to the compute nodes. Each compute node owns slices, which are the people actually carrying plates. On RA3 the plates live in managed storage, so you can add waiters without buying a new dining room full of cupboards.
Redshift is a massively parallel, columnar warehouse. A query is broken across slices. Each slice reads only the columns the query names, not the whole row. That is why SELECT * on a wide table is expensive, and why a sort key helps a filter that matches the order of the data.
On a provisioned cluster the leader node coordinates and does not hold the table data. Compute nodes hold slices. RA3 compute nodes cache hot data locally and keep the durable copy in Redshift Managed Storage. You can resize compute without resizing that storage one-for-one. Serverless hides the leader and the node list. You still get slices and a columnar engine. You size RPU instead of counting nodes.
| Part | Provisioned RA3 | Serverless |
|---|---|---|
| Coordination | A leader node you can see | Managed for you |
| Compute | RA3 nodes and their slices | RPU, between your base and max |
| Durable data | Redshift Managed Storage | Managed storage in the namespace |
| Failure domain | The cluster | The workgroup and namespace |
Redshift is not a row store for thousands of single-row updates. It is not a place to run an application transaction that must lock one customer and return in a millisecond. Use it for scans, joins, and aggregates over large sets. Small lookup tables are fine. A workload of constant single-row updates belongs in a transactional database, with the result loaded here.
Zone maps and sorted blocks let a slice skip data that cannot match a filter. That only helps when the filter matches the sort. The table-design lesson is where you choose distribution and sort. The architecture is why those choices exist: data is spread across slices, and each slice wants to skip blocks.
One node plans, many nodes work, and storage sits underneath them all.
Step 1 of 3The leader node receives your SQL, makes a plan and splits it into steps for the compute nodes.
EXPLAIN SELECT region, SUM(amount) FROM sales GROUP BY region;Step 2 of 3Each compute node is divided into slices. Every slice works on its own share of the rows at the same time, then results return to the leader.
SELECT node, slice FROM stv_slices;Step 3 of 3On RA3 nodes, data lives in Redshift Managed Storage on S3 with a fast local cache, so storage grows without adding nodes.
Cluster → Node type: ra3.xlplus
When a query is slow, ask which layer is busy. A queueing query is workload management. A query that moves rows between slices is distribution. A query that reads too many blocks is sort and encoding. The later lessons take those one at a time.
Checked against vendor documentation in October 2026. Screens and plan names still change, so confirm the control in your own instance.