DynamoDB, RDS, and Aurora
Lesson 4 of 5 in Choosing a Data Store.
The operational stores are where data engineers spend most of their time reading and almost none of it owning. They are usually the source, occasionally the sink, and regularly the thing someone is about to use for the wrong job — so the useful knowledge is their mechanics as a source and the exact shape of their limits.
The split is the OLTP and OLAP one. An operational store serves many small, selective, key-addressed requests, holds rows together on a page so a whole row is one read, and measures itself in milliseconds per request. An analytical store reads a few columns of an enormous number of rows and measures itself in rows per second. These are opposite physical layouts, which is why the first instinct — just run the report against production — is a reliably bad one, and why "which store" questions so often answer "both, with something between them".
Amazon DynamoDB is a key-value and document store whose performance promise rests on never searching. A Query must specify exactly one partition key value and may add a condition on the sort key; anything else is a Scan, which reads the whole table and filters afterwards. Capacity is provisioned (with auto scaling) or on-demand, which instantly absorbs up to double the previous peak. The limit that matters is per partition — roughly 3,000 read units or 1,000 write units per second — and it is a ceiling that table-level capacity cannot lift: write sharding exists precisely because a single hot key cannot be split any further.
Amazon Aurora separates the engine from a distributed storage layer that replicates every write six ways across three Availability Zones. Read replicas — up to 15 — attach to that same cluster volume rather than replaying a log, which is why replica lag is typically milliseconds and why adding a reader adds no storage cost. Aurora Serverless v2 scales capacity in place in fine-grained Aurora Capacity Units, without a reconnect.
Amazon RDS is the managed-instance option for the standard engines, and is chosen over Aurora when the engine demands it — Oracle and SQL Server are RDS only — when an application needs exact upstream behaviour, or when the workload is small enough that Aurora's floor costs more.
| Amazon DynamoDB | Amazon Aurora | Amazon RDS | |
|---|---|---|---|
How you ask |
| full SQL, joins, transactions, window functions | full SQL, in the engine’s own dialect |
Scaling shape | horizontal and effectively unbounded, subject to a per-partition ceiling | one writer; storage grows automatically; up to 15 readers on the same volume | one writer per instance; replicas lag asynchronously |
Schema | key attributes only — every other attribute is per item | declared and enforced on write | declared and enforced on write |
As a pipeline source | DynamoDB Streams, Kinesis Data Streams, or a zero-ETL integration to Redshift | zero-ETL to Redshift, logical replication for AWS DMS, or a reader for batch extracts | zero-ETL for MySQL, binary or write-ahead log for DMS, or a replica for extracts |
Operational cost | no instances at all; capacity is read and write units | instances or Aurora Capacity Units, plus consumed storage and I/O | instances plus provisioned storage, whether used or not |
Pick it when the stem says | “single-digit milliseconds at any scale”, “millions of requests”, “serverless” | “MySQL or PostgreSQL compatible”, “15 read replicas”, “scales with the workload” | “Oracle”, “SQL Server”, “lift and shift the existing database” |
Interactive sorting exercise: Each card is the one sentence from a stem that decides the store. Put it with the store that sentence selects — and notice that you are matching the *constraint*, never the data.
Key terms: Amazon DynamoDB, Amazon Aurora, Amazon RDS, Read replica, OLAP (online analytical processing)
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.