Amazon Redshift Architecture Explained: Nodes, Slices & MPP

Simple explanation

When you run a query, the leader node parses the SQL, builds an execution plan, and sends compiled work to every compute node simultaneously. Each node scans only the columns and rows it needs because Redshift stores data column by column, not row by row. Partial results flow back to the leader node, which assembles the final answer and returns it to your client.

This parallel execution model is called MPP (massively parallel processing). It is the reason Redshift can scan 100 billion rows in seconds on a dataset that would take hours on a single-node database. See the Amazon Redshift Overview for context on when to use Redshift at all before going deeper on architecture.

What Redshift architecture actually includes

A provisioned Redshift cluster has four structural layers:

• Leader node — single entry point for SQL connections and the query coordinator
• Compute nodes — store all user data and execute query work in parallel
• Slices — subdivisions of each compute node; the fundamental unit of parallelism
• MPP execution model — compiled query code runs across all slices simultaneously

Redshift Serverless uses the same columnar MPP engine but abstracts away nodes and slices. You configure Redshift Processing Units (RPUs) instead of choosing node types. The table design concepts (distribution styles, sort keys, columnar storage) still apply. See the Provisioned vs Serverless section below.

How Redshift executes a query

Here is the full sequence from the moment you press enter to the moment results appear:

1. Your SQL client connects to the leader node and sends the query.
2. The leader node parses the SQL, checks permissions, and validates syntax.
3. It builds an execution plan using table statistics and metadata. Prepend EXPLAIN to any query to inspect this plan before running it.
4. The leader node compiles the plan into C++ code and distributes it to every compute node simultaneously.
5. Each compute node executes against its local slices. Columnar storage means only the referenced columns are read from disk — irrelevant columns are skipped entirely.
6. If a join requires data held on a different slice or node, Redshift performs a redistribute step: a network shuffle that moves rows to where they are needed. This is the most expensive part of many queries. Matching distribution keys on join columns eliminates it.
7. Each compute node returns its partial result to the leader node.
8. The leader node applies any final ORDER BY, LIMIT, or top-level aggregation, then returns the full result to your client.

For practical examples of running queries and reading EXPLAIN output, see Running Your First Redshift Query.

Leader node

The leader node does the following:

• Parses incoming SQL and checks for syntax errors
• Builds an optimised execution plan using table statistics
• Distributes compiled query code to compute nodes
• Aggregates partial results into a final result set
• Manages cluster metadata: table definitions, column statistics, user permissions

The leader node does not store user data, does not scan tables, and does not participate in data-heavy query work. It is a pure coordinator. AWS does not charge extra for the leader node; it is included in the cluster price.

Compute nodes and slices

Compute nodes are where your data physically lives and where query execution happens. Each compute node is subdivided into slices. A slice has its own dedicated CPU threads, memory allocation, and storage. Data is distributed across all slices at load time, and every slice processes its portion of every query in parallel.

The number of slices per node is fixed by the node type:

• dc2.large: 2 slices per node
• dc2.8xlarge: 16 slices per node
• ra3.xlplus: 4 slices per node
• ra3.4xlarge: 8 slices per node
• ra3.16xlarge: 16 slices per node

A 4-node dc2.large cluster has 8 total slices. When loading data, Redshift distributes rows across all 8 slices. When running a query, all 8 slices work in parallel. Adding more nodes adds more slices, which adds more parallelism.

Columnar storage and why OLAP is different from OLTP

Row-based databases like RDS store each full row contiguously on disk. Running SELECT SUM(amount) FROM orders forces the engine to read all 50 columns of every row, including the 47 columns the query never touches.

Redshift stores each column separately. Every value in the amount column sits together on disk. That same query reads only the amount data. If a table has 50 columns and your query uses 3, you read roughly 6% of the I/O a row-store would require.

Columnar layout also enables far higher compression ratios. Values in the same column share a data type and are often similar in value (all prices, all dates, all status codes). Compression algorithms, which Redshift applies automatically at load time, achieve much better results on homogeneous data than on mixed row data.

This is the architectural reason Redshift exists as a separate service from RDS. It is not a faster version of MySQL. It is a different design built for a different workload. See Data Warehouses vs Data Lakes for more context on where Redshift fits in the broader data landscape.

Distribution styles

When Redshift loads data, it must decide which slice receives each row. This is the table’s distribution style. The wrong choice creates skew or forces expensive data movement during joins.

EVEN distribution

Rows are distributed across slices in round-robin order, regardless of content. Every slice ends up with roughly the same number of rows. Use EVEN for tables that are rarely joined to other large tables.

KEY distribution

You designate one column as the distribution key (DISTKEY). Rows with the same DISTKEY value land on the same slice. When you join two tables on matching DISTKEY columns, Redshift runs that join locally on each slice with no network shuffle and no redistribute step.

ALL distribution

A full copy of the table is stored on every compute node. Joins never need to shuffle data. Only practical for small dimension tables (a few million rows at most). Using ALL on a large table multiplies your storage cost by the number of compute nodes and significantly slows data loads.

AUTO distribution

Redshift starts with ALL distribution for small tables, then automatically switches to EVEN as the table grows. This is the recommended default for most tables. Let Redshift decide unless you have a clear reason to override it.

Sort keys

Sort keys control the physical order of rows within each slice. When a query filters with WHERE order_date BETWEEN ‘2025-01-01’ AND ‘2025-03-31’, Redshift checks the zone map, a per-block min/max index, to determine whether each 1 MB block of data contains any rows in the date range. Blocks outside the range are skipped without touching disk. This is called zone map pruning.

Without a sort key on order_date, rows are stored in arbitrary order. Redshift cannot skip any blocks and scans the entire table for every date-filtered query.

Match the sort key to your most common filter column. If most queries filter by date, order_date is the right sort key. If most queries filter by region, use region. For a full treatment of compound vs interleaved sort keys, see the sort keys guide.

Provisioned Redshift vs Redshift Serverless

Provisioned Redshift gives you explicit control: you choose node types, node counts, and manage the cluster. The node/slice model described throughout this page is fully visible to you. You tune distribution styles and sort keys knowing exactly how many slices your data will be spread across.

Redshift Serverless removes that infrastructure layer. You configure RPU (Redshift Processing Unit) capacity instead of nodes. AWS allocates compute automatically and scales to zero when idle. You do not choose node types or count slices.

For pricing differences between the two models, see Redshift Pricing Explained.

Redshift vs RDS architecture

The most common confusion newcomers have is treating Redshift like a faster version of RDS. It is not. They are built for different purposes at the architecture level.

The reason Redshift exists as a separate service is that columnar storage and MPP execution are fundamentally incompatible with the transactional consistency guarantees that make RDS fast for OLTP. You use RDS for your application database and Redshift for analytics on top of that data. For a deeper look at how data moves between the two, see ETL vs ELT and AWS Glue Overview.

When to use this knowledge

This architecture page is not abstract background. It directly informs practical decisions:

• Choosing DISTKEY and SORTKEY: match DISTKEY to join columns, match SORTKEY to filter columns.
• Debugging slow joins: run EXPLAIN and look for a redistribute step. If it is present, your tables do not share a distribution key on the join column.
• Understanding skew: it comes from a low-cardinality DISTKEY sending most rows to the same slice.
• Understanding why Redshift behaves differently from RDS: it does not have row-level locks, it is slow at single-row inserts, and VACUUM must be run manually to reclaim space from deleted rows.
• Making sense of query costs: network shuffles and full-table scans are expensive. Architecture decisions either eliminate them or guarantee them.
• Loading data efficiently: the Loading Data into Redshift guide explains why the COPY command (which loads all slices in parallel) is dramatically faster than single-row INSERT statements.