DynamoDB vs Redshift

DynamoDB and Amazon Redshift are rarely alternatives. DynamoDB is an operational database — single-digit-millisecond reads and writes against known keys, serving live application traffic. Redshift is "a fully managed, petabyte-scale data warehouse service in the cloud," built to scan and aggregate large datasets for reporting and analytics. Teams that run both are the normal case, and AWS ships a managed integration to move data one way between them.

Should you use DynamoDB or Redshift?

Use DynamoDB for the application's live data: orders being placed, sessions being read, records fetched by key. Use Redshift when someone needs to ask questions across the whole dataset — revenue by region and month, cohort retention, a dashboard joining several sources. The question "which one" usually resolves to "DynamoDB for the write path, Redshift for the analysts," with the zero-ETL integration in between.

DynamoDB vs Redshift at a glance

Characteristic	DynamoDB	Redshift
Workload	Operational (OLTP-style) — high-volume reads and writes by key	Analytical — scans and aggregations over large datasets
Data model	Schemaless NoSQL items up to 400 KB; attributes vary per item	Relational tables with declared columns, distribution keys and sort keys
Query language	Native API (`GetItem`, `Query`, `Scan`, …) plus PartiQL	Full SQL, with the BI and SQL tooling that implies
Joins and aggregates	No server-side joins; aggregation is not a server-side operation	Joins, window functions, `GROUP BY` and the rest of analytical SQL
Access pattern	Designed around known keys; scans are the expensive exception	Designed to scan — reading a lot of rows is the normal case
Latency	Single-digit milliseconds per request	Seconds to minutes per analytical query, over far more data
Scaling	Serverless; partitions managed by AWS	Serverless workgroups or provisioned clusters; capacity sized to the query workload
Freshness	Read-your-write on demand	As fresh as whatever loads it — the zero-ETL integration lands updates every 15–30 minutes
Pricing model	Per-request or provisioned capacity, plus storage	Compute capacity plus storage; idle serverless warehouses are not billed for compute

When DynamoDB is the better choice

Live application traffic. Predictable single-digit-millisecond reads and writes against known keys, at any request rate.
Schema that varies by item. Heterogeneous items in one table are normal in DynamoDB; a warehouse wants declared columns.
Serverless operations. No cluster to size, patch or pause.
Write-heavy paths. DynamoDB absorbs high-volume writes as its primary job; a warehouse is optimised for bulk load and read.

When Redshift is the better choice

Questions that cross the whole table. Aggregating a year of orders is a scan by nature, which is exactly the access pattern DynamoDB asks you to avoid and Redshift is designed for.
Joins across many sources. Warehouses join. DynamoDB has no server-side join.
BI tooling. Redshift speaks SQL over JDBC/ODBC, so it drops into existing dashboards and "the same SQL-based tools and business intelligence applications that you use today."
Analysis that must not disturb production. Running analytics against a replicated copy keeps the load off the table serving your users.

Using them together

The standard pattern is one-directional: DynamoDB serves the application, a copy lands in Redshift, analysts work on the copy. AWS supports two routes — the older COPY command, which loads directly "from Amazon S3 or Amazon DynamoDB into Amazon Redshift," and the managed zero-ETL integration, which keeps the copy current on its own.

What the zero-ETL integration actually does

"Zero-ETL" suggests a live view. It is not one, and the details matter before you design a dashboard around it.

It is a replication pipeline on a timer. AWS is precise: "On activation, the integration exports the full DynamoDB table to populate the Amazon Redshift database." Then "the zero-ETL integration then incrementally replicates updates from DynamoDB to Amazon Redshift every 15-30 minutes using DynamoDB incremental exports." So the data in Redshift is up to half an hour stale. That is fine for daily reporting and wrong for anything a user is meant to see reflect their last action.

Point-in-time recovery is mandatory — and now the reason is obvious. The prerequisite is stated plainly: "A zero-ETL integration between Amazon DynamoDB and Amazon Redshift requires your source DynamoDB table to have Point-in-time recovery (PITR) enabled." AWS documents the requirement in one place and the mechanism in another, and does not connect them, but the resource-based policy you must attach gives the game away — it grants redshift.amazonaws.com the action dynamodb:ExportTableToPointInTime. The integration is built on DynamoDB's export-to-S3 machinery, and that machinery reads from the continuous backup. No PITR, no export, no integration.

That has a budget consequence people meet late: enabling PITR on a large table is a standing charge on the table's size, incurred for the analytics pipeline rather than for recovery. Price the integration as "Redshift plus PITR," not as Redshift alone — the free DynamoDB pricing calculator will size the storage side of that before you commit.

Two constraints that block existing tables. Both are documented limitations, and both are awkward to fix after the fact:

"The DynamoDB table and Amazon Redshift cluster need to be in the same Region." A warehouse consolidating several Regions cannot pull them all in through this path.
"The source DynamoDB table must be encrypted with either an Amazon-owned or Customer-managed AWS KMS key. Amazon managed encryption is not supported for the source DynamoDB table." Tables created under AWS-managed encryption need their encryption settings changed before an integration can be created.

Where the shape of your data bites. DynamoDB items are heterogeneous by design; warehouse tables have columns. A single-table design holding several entity types under one partition-key convention does not become a clean star schema by being replicated. Plan for modelling work in Redshift after the data lands — the integration removes the pipeline, not the schema design.

When you do not need a warehouse yet

Not every aggregate is an analytics problem. A large share of "we should put this in Redshift" starts as one question — how many items are in this state, what is the total for this customer, which partition keys dominate — asked occasionally, by an engineer, against one table.

DynoTable's SQL Workbench answers that class of question directly against DynamoDB, on demand: real SQL with COUNT, SUM, AVG, MIN, MAX, GROUP BY, HAVING and DISTINCT, plus INNER/LEFT JOIN. The positioning is deliberately narrow — SQL within DynamoDB's access-pattern rules. It is a single SELECT; there are no CTEs, no UNION, no window functions, and no scalar subqueries; a join target must be a partition key or a GSI partition key. Results stream with a partial badge and become exact once the query runs to the end, and reading the data still costs the reads it costs.

That is not a substitute for a warehouse, and the limits above are the honest boundary. But it is a faster answer than a replication pipeline, a PITR charge and a schema design — and it tells you whether the question was worth a warehouse before you build one. Running Workbench queries is a paid feature; the editor and autocomplete are free. DynoTable is a closed-source commercial app; this page describes what it does, not how it is built.

FAQ

Can Redshift replace DynamoDB?

No, not for application traffic. Redshift is a data warehouse built to scan and aggregate; it is not designed to serve high-volume key lookups at single-digit-millisecond latency. The two run alongside each other, with DynamoDB serving the application and a replicated copy in Redshift serving analytics.

How fresh is DynamoDB data in Redshift?

With the zero-ETL integration, up to about 30 minutes stale. AWS documents that after the initial full export it "incrementally replicates updates from DynamoDB to Amazon Redshift every 15-30 minutes using DynamoDB incremental exports." Treat it as near-real-time reporting, not a live view.

Why does the zero-ETL integration require PITR?

Because it is built on DynamoDB's point-in-time export. The resource-based policy the integration needs grants Amazon Redshift the dynamodb:ExportTableToPointInTime action, and that export reads from the continuous backup that PITR maintains. Enabling PITR is therefore a real, ongoing cost of the integration.

Learn when to use DynamoDB and why scans are expensive.
Compare DynamoDB and PostgreSQL for the operational relational question.
Model access patterns up front with single-table design.
Size the storage and capacity side with the free DynamoDB pricing calculator.
Download DynoTable to query and aggregate your DynamoDB tables directly.

References

Last verified 2026-08-02 against the official AWS Redshift Management Guide and DynamoDB Developer Guide.