What is Amazon Redshift? A plain-English explainer

What a data warehouse actually is

A data warehouse is a database structured and optimised specifically for analysis rather than for the moment-to-moment operations of an application. Instead of storing data the way an application needs to read and write it quickly one record at a time, a data warehouse organises data — often pulled in from multiple systems — in a way that makes it efficient to summarise, aggregate and query across huge numbers of records at once.

Our data-lake-vs-data-warehouse explainer covers the concept, and how it differs from a data lake, in more depth. Redshift is AWS’s implementation of that idea: a data warehouse you do not have to build or operate yourself.

What Redshift is actually for

Redshift exists to run analytical queries — the kind that scan millions or billions of rows to answer questions like "what were total sales by region last quarter" — quickly and at scale. It is the engine behind business intelligence dashboards, regular reporting, and the kind of exploratory analysis that data analysts and data engineers run against an organisation’s historical data.

It is a fully managed service: AWS handles the provisioning, patching and operational work of keeping a data warehouse running, rather than a team owning that infrastructure themselves. That is the same trade every AWS managed service makes — you focus on the data and the queries, AWS runs the machinery underneath.

Redshift vs a transactional database like RDS

Amazon RDS and Amazon Redshift are both relational, but they are built for opposite jobs. RDS is tuned for transactional workloads — an application constantly reading and writing individual records, such as processing an order or updating a user profile — where speed on small, frequent operations matters most. Redshift is tuned for analytical workloads — fewer, much larger queries that scan huge swathes of historical data at once — where summarising millions of rows efficiently matters most.

Trying to run heavy analytics directly against a transactional database like RDS tends to slow down the very application it supports, because the two access patterns compete for the same resources. The common pattern instead is to keep RDS handling day-to-day transactions and periodically move or copy that data into Redshift for analysis, so each database does the job it was built for.

Redshift vs a data lake

A data lake stores data in its raw, often unstructured or semi-structured form, cheaply and at scale, without requiring it to be organised before it is stored — useful when you are not yet sure how the data will be used. Redshift, as a data warehouse, expects data to be structured and typically transformed before it arrives, which makes it faster to query but less flexible about what kinds of data it can hold.

The two are frequently used together rather than as alternatives: raw data lands in a data lake first, and the subset that is ready for structured reporting is loaded into Redshift. Which one to reach for depends on whether the data is already well-defined and the questions you want to ask are already known.

When you would use Redshift

Redshift makes sense once an organisation has enough historical, structured data that answering business questions against it — trends, aggregates, comparisons over time — has become a regular need, and a transactional database can no longer serve that need without slowing everything else down. It is less appropriate for storing an application’s live, frequently changing operational data, which is what RDS or a NoSQL database is built for.

Where Redshift appears in certification study

Redshift is central to the AWS Certified Data Engineer Associate, where designing analytics pipelines and choosing the right storage for structured, query-heavy workloads is core material. It also appears in the Solutions Architect Associate as one option when an architecture needs an analytics layer, and the underlying data warehouse concept is relevant to the Microsoft Fabric Data Engineer Associate, which covers the equivalent idea on Azure.

As with the other services covered here, this article deliberately stops at the concept level. The exam-depth detail on configuring and querying a warehouse belongs in our /revision study material, not in a beginner explainer.