Skip to main content
Cloud & AI Hub
Browse
Glossary AI Directory Playgrounds Models Prompts Explainers Strategy Matrix Benchmark Decoder
Databases

Amazon Redshift

AWS's petabyte-scale data warehouse — columnar, massively parallel analytics on data too big for a transactional database, and the wrong tool for anything transactional.

What is Redshift?

Amazon Redshift is a data warehouse: a columnar, massively-parallel-processing (MPP) database built to run complex analytical queries over terabytes to petabytes — aggregations, joins, and scans across huge datasets that would crush a transactional database like RDS. It’s the “answer analytical questions across all our data” tool, distinct in purpose from operational databases, and it anchors many AWS analytics stacks alongside S3 and Athena.

Columnar + MPP — why it’s fast at analytics and slow at transactions

Two architectural choices define Redshift and its tradeoffs. Columnar storage: data is stored by column, not row, so an analytical query touching 3 of 50 columns reads only those columns’ data — dramatically less I/O, plus excellent compression (similar values cluster). MPP: queries are split across many nodes running in parallel, so a scan of a billion rows divides across the cluster. Together these make aggregate analytics fast. The flip side is equally important: Redshift is terrible at transactional workloads — single-row lookups, frequent small updates, and high-concurrency point queries are exactly what columnar MPP is bad at. Using Redshift as an application database is a category error; it’s a warehouse, queried by analysts and BI tools, loaded in bulk.

Redshift vs the alternatives

The analytics landscape shifted, and honest guidance must acknowledge it. Redshift Serverless removed the always-on cluster cost that made classic Redshift expensive for spiky analytics. But Athena (serverless SQL directly on S3, pay-per-scan) competes for ad-hoc and lower-volume analytics without any cluster, and Snowflake/BigQuery compete hard on the managed-warehouse experience and cross-cloud reach. The decision hinges on: sustained heavy analytical load and tight AWS integration favor Redshift; intermittent queries on data already in S3 favor Athena; multi-cloud or operational-simplicity priorities may favor Snowflake/BigQuery. Distribution keys and sort keys are Redshift’s performance-tuning knobs — get them wrong and even Redshift crawls.

What people get wrong

  • Redshift as an application database — columnar MPP is built for bulk analytics, not transactional point queries.
  • Ignoring distribution/sort keys: bad key choices cause data skew and cross-node shuffles that tank query performance.
  • Always-on clusters for spiky analytics — Serverless or Athena often fit intermittent workloads far more cheaply.

Primary source: Amazon Redshift documentation

Historical figures and technical concepts for informational purposes only. Not technical, professional, legal, or financial advice. Sources: Official Documentation.