What Is Amazon Redshift? Architecture, Use Cases & Serverless Explained

Amazon Redshift is AWS’s managed cloud data warehouse — a database engine built specifically for analytical SQL queries across large datasets. It solves a specific problem: running complex reporting queries on billions of rows without slowing down your production application database. If you need to serve a web application or API, Redshift is the wrong tool. If you need to aggregate years of business data for dashboards and reports, it is exactly the right one.

Simple explanation

Here is an analogy that makes this click for most beginners.

A filing cabinet is great for finding and updating individual files. You can pull out a single folder in seconds and replace it just as fast. That is your application database like Amazon RDS: optimised for fast, small, individual reads and writes.

A library archive is different. It is not built for speed on single lookups. It is built for searching across thousands of documents at once, finding patterns, and producing reports. That is Redshift: optimised for scanning enormous volumes of data and aggregating the results.

The technical term for what Redshift does is OLAP (Online Analytical Processing), as opposed to OLTP (Online Transaction Processing) for application databases. OLAP means large read-heavy queries that touch many rows. OLTP means many small fast reads and writes happening concurrently.

Redshift speaks standard SQL, so if you already know SQL you can query it immediately. The difference is in what happens underneath: columnar storage, parallel execution across a cluster, and a bulk-load data model that makes large aggregations fast and cheap.

Why teams use Amazon Redshift

Redshift exists because analytical queries are fundamentally different from the queries a web application issues. Running a query that scans 500 million rows on your production RDS database would lock up the system. Redshift gives those workloads a dedicated home.

Business intelligence dashboards. Tools like Tableau, Looker, and QuickSight connect directly to Redshift and issue aggregation queries that would be impractical on RDS.
Historical trend reporting. “Show me monthly revenue by region for the past three years, broken down by product category.” This query scans hundreds of millions of rows. Redshift returns it in seconds.
Aggregating data from operational systems. Pull data from RDS, DynamoDB, application logs, and third-party APIs into one place so analysts can query across all of it without knowing where each piece lives.
Warehouse-style financial reporting. Finance and operations teams that need reliable, scheduled reports over large datasets benefit from Redshift’s ability to run multiple complex queries in parallel.
Near real-time analytics. When combined with Kinesis Data Firehose, Redshift can hold data that is minutes old, enabling dashboards that update on near real-time data rather than stale overnight loads.

Once you understand the concepts on this page, the next practical step is running your first Redshift query to get connected and start working with actual data.

How Amazon Redshift works

Three architectural decisions make Redshift fast for analytical workloads: columnar storage, massively parallel processing, and a leader/compute node split. Understanding these at a high level helps you make better decisions about workload fit and performance tuning.

Columnar storage

Picture a spreadsheet with 10 million rows and 50 columns. In a row-based database like PostgreSQL, every row is stored together on disk. When you query SUM(revenue), the database reads all 50 columns of all 10 million rows just to get the one column it needs.

Redshift stores data by column instead. All revenue values sit together on disk. That same aggregation reads only the revenue column, which is potentially 10 to 20 times less data. Columnar data also compresses very efficiently because similar values sit next to each other, which reduces both storage cost and I/O time.

Massively parallel processing (MPP)

Think of MPP like a team of people splitting up a large pile of documents. Instead of one person reading through all 500 million rows, ten compute nodes each handle 50 million rows simultaneously, then combine their results. A query that would take minutes on a single machine finishes in seconds.

The larger and more evenly distributed your data across nodes, the more pronounced this advantage becomes.

Leader node and compute nodes

When you connect to Redshift, you connect to the leader node. It receives your SQL, builds a query execution plan, distributes work to the compute nodes, and assembles the final result. You never interact with compute nodes directly. For a deeper look at how slices, distribution keys, and sort keys fit together, see the Redshift architecture guide.

Bulk loading, not row-by-row writes

Redshift is optimised for loading data in bulk and then querying it. Data flows in from sources like S3 or Kinesis, sits in Redshift, and is read by analysts and BI tools. It is not a live transaction store that your application writes to on every user action.

The OLAP vs OLTP distinction matters more than it sounds

Every architectural decision in Redshift — columnar storage, distribution keys, bulk loading — follows from it being an OLAP system. If a Redshift behaviour confuses you, ask yourself: “does this make sense for a system designed to scan billions of rows in batch?” It almost always does.

Redshift vs RDS

The most common confusion for beginners is when to use Redshift versus Amazon RDS. The short rule: RDS is for your application database (OLTP), Redshift is for your analytics warehouse (OLAP). They serve completely different workloads and are commonly used together.

Characteristic	RDS	Redshift
Workload type	OLTP (transactional)	OLAP (analytical)
Query pattern	Many small, fast queries	Few large, complex queries
Storage format	Row-oriented	Column-oriented
Typical query time	Milliseconds	Seconds to minutes
Ideal data size	GBs to low TBs	Hundreds of GBs to PBs
Concurrent writes	High (thousands/sec)	Low (bulk loads only)
Typical users	Application backend	Analysts and BI tools

Choose Redshift when you are running analytical queries that scan hundreds of millions of rows, feeding BI tools, or aggregating data from multiple operational sources for reporting.

Choose RDS when your application needs fast individual reads and writes, you have concurrent users making thousands of small queries per second, or you need ACID transactions with real-time consistency.

In most production architectures both are present. RDS serves the live application, and data is periodically loaded from RDS into Redshift via AWS Glue or a similar pipeline so analysts can query the warehouse without touching production.

Redshift Serverless vs provisioned clusters

Redshift has two deployment modes. Choosing the wrong one is one of the most common cost mistakes with this service.

Provisioned clusters

You choose a node type and node count, and Redshift runs a cluster for you around the clock. You pay per node-hour whether queries are running or not. This is cost-effective when your warehouse is under heavy use for most of the working day. You can purchase Reserved Instances for discounts of up to 75% compared to on-demand pricing.

Think of this like renting a dedicated office space. You pay the monthly rate regardless of whether you show up, but it is cheaper per hour than paying for a hotel room every time you need a desk.

Redshift Serverless

No cluster to manage. You define a namespace and workgroup, and Redshift scales compute automatically. You are billed in RPU-seconds (Redshift Processing Units) only while queries are running. There is a minimum per-query charge.

This is more like a pay-per-use coworking space. Great value if you only show up a few hours a week. Expensive if you are there every day.

How to choose between them

Start with Redshift Serverless to prototype, understand your query patterns, and measure actual RPU consumption. Once you have real usage data, compare Serverless costs against a provisioned cluster with Reserved Instances. Provisioned typically becomes cheaper once your warehouse runs queries for more than roughly 6 to 8 hours per day.

For a full cost comparison with worked examples, see the Redshift pricing guide.

How data gets into Redshift

Redshift is not an application database. Data flows in from other sources in bulk, then analysts query it. Understanding the ingestion paths helps you design a pipeline that actually scales.

S3 + COPY command (most common)

The recommended path for most batch loads. You stage files in Amazon S3 (CSV, JSON, Parquet, ORC, or Avro), then issue a COPY command to load them into a Redshift table. COPY is parallelised across compute nodes and is dramatically faster than INSERT statements for any meaningful data volume. For the full COPY workflow including error diagnosis, see loading data into Redshift.

Kinesis Data Firehose (near real-time)

Firehose streams records into a Redshift table with minimal lag. Under the hood, it stages data in S3 first, then issues a COPY command automatically. This gives you a streaming ingestion path without writing custom ETL code. For more on building streaming pipelines, see streaming pipelines with Kinesis.

AWS Glue (complex ETL)

AWS Glue is the managed ETL service. Glue jobs read from RDS, S3, DynamoDB, or external sources, apply Spark-based transformations, and write to Redshift. Use Glue when your load pipeline involves joins, business logic, format conversion, or multiple source systems. For pipeline architecture patterns, see designing data pipelines.

Direct INSERT is almost always the wrong choice

Individual INSERT statements create small unsorted micro-blocks on disk and do not benefit from Redshift’s parallel loading. For anything beyond a handful of reference rows, stage your data in S3 and use COPY. Even 10,000 rows loads faster with COPY than with individual INSERTs.

When to use Redshift

Redshift is a strong fit when you hit one or more of these situations:

Analytical queries scan hundreds of millions or billions of rows and take too long on RDS
Business analysts need BI dashboards that run complex aggregations without affecting production database performance
You need to aggregate data from multiple operational systems (RDS, application logs, third-party exports) into a single queryable location
Multiple analysts need to run independent queries simultaneously over the same historical dataset
You are building company-wide reporting that needs to scale as data volume grows
Your dataset is at least in the hundreds of gigabytes and growing

When not to use Redshift

Redshift is a poor fit for these scenarios:

You need a transactional application database. Redshift does not handle thousands of concurrent small reads and writes. Use RDS or Aurora instead.
Your dataset is small. Under 50 GB, a standard RDS instance with a read replica handles analytical queries well enough. Redshift adds cost and operational complexity you do not yet need.
Your application writes individual rows continuously. Redshift is designed for bulk loads. Row-by-row inserts perform poorly and cost more than alternatives built for that pattern.
You need sub-second query latency at high concurrency. Redshift queries take seconds to minutes. For real-time low-latency queries at high throughput, consider DynamoDB or ElastiCache.
Your queries are mostly key-value point lookups. “Give me the record for user ID 12345” is a job for RDS or DynamoDB. Redshift is overkill and slower than row-based databases for single-row retrieval.

Common beginner mistakes

Using Redshift as an application database. If your application writes individual rows on every user action, you are using the wrong tool. Redshift is a warehouse, not a transaction store. Point your application at RDS or DynamoDB and load data into Redshift in bulk on a schedule.
Loading data with INSERT instead of COPY. Individual INSERT statements are extremely slow because each one creates a small unsorted block on disk. Even loading 10,000 rows is faster with COPY than with individual INSERTs. Stage your files in S3 and always use COPY for bulk loads.
Paying for a provisioned cluster that sits idle most of the day. If your warehouse is queried for only a few hours each morning, you are paying node-hour charges for idle compute the rest of the time. Use Redshift Serverless, or pause and resume a provisioned cluster outside working hours to cut costs significantly.
Ignoring distribution and sort keys. Redshift distributes data across nodes based on the distribution key. A poor choice causes data skew: some nodes do most of the work while others sit idle. Sort keys affect how efficiently Redshift skips blocks when filtering. Defaults are fine initially, but as data grows you will need to understand these. See the performance optimisation guide for a practical walkthrough.
Not running VACUUM and ANALYZE after large loads. Deleted and updated rows leave dead space in Redshift blocks. VACUUM reclaims that space and re-sorts data on disk. ANALYZE updates the query planner’s statistics so it builds efficient execution plans. Both should run after large data loads.
Confusing Redshift with a data lake. Redshift is a structured SQL warehouse. A data lake (typically S3-based) stores raw, unstructured, and semi-structured data cheaply at scale. Many architectures use both: the lake holds raw data, and curated data is loaded into Redshift for querying. See data warehouses vs data lakes for the full comparison.

The distribution key mistake that silently kills performance

If you choose a distribution key with low cardinality (such as a boolean or a status field with only three values), most rows will land on a handful of nodes and the rest sit empty. Queries slow down dramatically because only a few nodes do all the work. This is hard to spot without looking at node-level query diagnostics. Read the architecture guide before choosing distribution keys on any table expected to grow large.

Redshift sits at the centre of a larger data architecture. These topics connect directly to how it is deployed and used in practice:

Data warehouses vs data lakes — understand the boundary between Redshift and S3-based lake architectures, and when you need both
ETL vs ELT — the two pipeline patterns for getting data into a warehouse, and when each applies to Redshift
Redshift Architecture — leader nodes, compute nodes, slices, and distribution keys in depth
Designing Data Pipelines — how to structure the data flow from operational sources into a warehouse like Redshift
Redshift Performance Optimisation — distribution keys, sort keys, VACUUM, and query tuning practices

Frequently asked questions

What is Amazon Redshift used for?

Redshift is a managed cloud data warehouse built for analytical SQL queries (OLAP). It handles things like BI dashboards, historical trend analysis, and aggregations over billions of rows — workloads that would overwhelm a standard application database. It is not designed for high-frequency transactional reads and writes, which is what RDS and DynamoDB handle.

What is the difference between Redshift and RDS?

RDS is an OLTP database optimised for fast individual queries from a live application — thousands of small reads and writes per second. Redshift is an OLAP warehouse optimised for scanning and aggregating large volumes of historical data. If your query scans billions of rows to produce a report, use Redshift. If your web app needs to look up a single customer record in milliseconds, use RDS. Most architectures use both.

Is Redshift a database?

Redshift is a database in the sense that you connect to it with SQL and it stores data in tables. But it is an analytical data warehouse, not an application database. The key difference is the workload: Redshift is optimised for scanning and aggregating large volumes of data, not for the high-concurrency transactional reads and writes that application databases handle.

What is Redshift Serverless?

Redshift Serverless is a deployment mode where you do not provision or manage clusters. You pay per RPU-second (Redshift Processing Unit) only while queries are running. It scales automatically and suits variable or unpredictable workloads well. For steady, high-volume workloads running most of the day, provisioned clusters with Reserved Instance pricing are usually cheaper.

When should a beginner choose Redshift?

Choose Redshift when you have analytical queries that scan large amounts of data — typically hundreds of gigabytes to petabytes. Common triggers: your analysts are running slow queries on production RDS, you need BI dashboards over historical data, or you are aggregating event data from multiple operational systems. If your data is small (under 50 GB) or your queries are transactional, a standard database is likely the better choice.

Last verified: 11 May 2026 Cloud services change frequently. Verify details against official documentation before making infrastructure decisions.