Databases like Amazon RDS are usually built for OLTP workloads — Online Transaction Processing — think “add one order to the orders table” or “look up one customer’s profile.” These are small, frequent, precise operations. Amazon Redshift is built for the opposite kind of workload: OLAP, or Online Analytical Processing — questions like “what was total revenue by region for the last three years, broken down by product category?” These queries scan huge amounts of historical data and are asked far less often, but each one touches millions or billions of rows.

Redshift is a fully managed, petabyte-scale cloud data warehouse. It stores data in a way optimized for scanning entire columns of data quickly (rather than entire rows, like most application databases), and it spreads that data and the work of querying it across multiple computers working together.

A Redshift cluster is made of a leader node and one or more compute nodes. The leader node never stores your table data. Instead, it receives your SQL query, creates an execution plan, and hands out pieces of that plan to the compute nodes. Each compute node is further divided into slices — smaller units that each hold a portion of the data and run their own share of the query independently.

flowchart TB
    A[SQL Client or BI Tool] -->|Query| B[Cluster Endpoint]
    B --> C[Leader Node]
    C -->|Plan Fragment 1| D[Compute Node 1]
    C -->|Plan Fragment 2| E[Compute Node 2]
    C -->|Plan Fragment 3| F[Compute Node 3]
    D --> D1[(Slice A)]
    D --> D2[(Slice B)]
    E --> E1[(Slice C)]
    E --> E2[(Slice D)]
    F --> F1[(Slice E)]
    F --> F2[(Slice F)]
    D1 --> C
    D2 --> C
    E1 --> C
    E2 --> C
    F1 --> C
    F2 --> C
    C -->|Combined Result| B
        

This is called a Massively Parallel Processing (MPP) architecture. The more compute nodes you add, the more slices exist to divide the work, and the faster large scans generally complete — as long as your data is spread evenly across those slices.

Two internal techniques make Redshift fast: columnar storage and zone maps. In a row-based database, a table’s data is stored one full row at a time — even if your query only needs 2 out of 40 columns, the engine often reads all 40. In Redshift’s columnar format, each column is stored separately, so a query needing 2 columns reads only the data for those 2 columns, skipping the other 38 entirely.

On top of that, Redshift keeps a zone map for each block of column data — essentially a mini index recording the minimum and maximum value stored in that block. If your query filters for dates after 2024 and a block’s zone map shows it only contains 2019 data, Redshift skips reading that block entirely, without ever opening it.

Redshift also automatically applies compression encodings to columns based on the data patterns it detects, shrinking storage size and, just as importantly, shrinking the amount of data that has to be read from disk during a scan.

Notice the symmetry: data typically enters Redshift in bulk from S3 and, when needed elsewhere, leaves in bulk back to S3 — Redshift is built around moving large volumes efficiently, not one row at a time.

The core trade-off is throughput on large scans versus latency on small operations. Redshift is deliberately optimized to move through billions of rows efficiently, which means it is the wrong tool for an application expecting millisecond single-row responses — that job belongs to RDS, DynamoDB, or a caching layer.

Three table design choices dominate Redshift performance. The distribution style decides how rows are spread across slices: KEY distribution groups rows sharing a column value onto the same slice (useful for join performance), ALL copies a small table to every node (useful for frequently-joined lookup tables), and EVEN spreads rows round-robin when no clear pattern exists. The sort key determines the physical order data is stored in, directly powering how effective zone maps are at skipping irrelevant blocks.

Concurrency scaling automatically adds temporary compute capacity when many queries arrive at once, so a spike in dashboard traffic does not slow down everyone else’s queries. On RA3 node types, storage and compute scale independently — you can grow your data volume without necessarily buying more compute power, unlike older DC2 node types where storage was fixed to the compute you provisioned.

Redshift continuously monitors the health of its nodes. If a compute node fails, Redshift automatically replaces it and restores its data from the cluster’s replicated data and periodic snapshots, without requiring manual intervention. For multi-node clusters, data is also replicated across nodes within the cluster, so the loss of one node’s disk does not mean data loss.

Automated snapshots are taken regularly and stored in Amazon S3, which itself is designed for extremely high durability. These snapshots allow you to restore an entire cluster to a previous point in time, or even launch a completely new cluster from a snapshot taken in a different AWS region for disaster recovery purposes.

For workloads that cannot tolerate any cluster downtime during maintenance or resizing, Redshift also supports classic and elastic resize operations designed to minimize the disruption window as much as possible.

Like most AWS data services, Redshift clusters are typically launched inside a VPC, reachable only from sources permitted by security group rules. Encryption at rest using AWS KMS protects the underlying data blocks and snapshots, while SSL/TLS connections protect data moving between clients and the cluster.

Amazon CloudWatch collects cluster-level metrics such as CPU utilization, disk space, and query throughput automatically. Redshift also exposes detailed system tables and views — internal tables you can query with plain SQL — that reveal exactly how a query was planned, how long each stage took, and which slices did the most work.

The built-in query monitoring rules feature lets administrators automatically flag or even stop queries that consume excessive resources, preventing one poorly written analytical query from starving the rest of the workload.

Redshift offers two deployment models. A provisioned cluster requires you to choose node type and node count upfront, giving predictable performance and cost for steady workloads. Redshift Serverless removes that decision entirely — capacity scales automatically based on workload demand, and you pay only for the compute actually used, which suits unpredictable or intermittent analytical workloads.

Redshift Spectrum deserves special mention: it lets a Redshift cluster run SQL directly against files stored in Amazon S3, using a separate fleet of compute managed by AWS for that specific scan, without ever loading the data into the cluster itself — useful for querying rarely-accessed historical data cheaply.

A common, effective pattern is the lake house architecture: keep raw and historical data cheaply in S3, use Redshift Spectrum to query it occasionally, and load only frequently-accessed, curated data into the cluster itself. Another pattern, materialized views, precomputes and stores the result of a complex, frequently-run query, refreshing it periodically instead of recalculating from scratch every time.