Aurora vs RDS vs DynamoDB

Aurora vs RDS and RDS vs DynamoDB are two of the most common database questions on the AWS Associate exams. The question usually gives you a few requirements, such as relational or not, how much it must scale, and how little you want to manage, and asks which service fits.

This page keeps it practical. First comes a quick "if the requirement says X, pick Y" table, then a side-by-side comparison, then the traps that catch people out. Everything is checked against the AWS documentation, with a link on every row.

Reviewed against the AWS documentation

At a glance

Amazon Aurora

A fully managed relational database engine compatible with MySQL and PostgreSQL, built on a shared storage volume that grows automatically. It is part of the Amazon RDS family.

  • Relational workloads that need higher throughput and faster failover than a standard RDS instance
  • Many read replicas that share one storage volume
  • Multi-Region reads and disaster recovery with Aurora Global Database
  • Unpredictable relational load, using Aurora Serverless
AWS docs

Amazon RDS

A managed service for running a relational database such as MySQL, PostgreSQL, MariaDB, Oracle Database, SQL Server or Db2. AWS handles backups, patching and failure recovery.

  • Relational workloads that need a specific engine, such as Oracle, SQL Server or Db2
  • Lift-and-shift of an existing database with minimal changes
  • Standard relational apps where Aurora features are not needed
AWS docs

Amazon DynamoDB

A serverless, fully managed NoSQL database with single-digit millisecond performance at any scale. It supports key-value and document data models.

  • Key-value or document access patterns known up front
  • Massive scale with consistent low latency and no servers to manage
  • Spiky or unpredictable traffic with on-demand capacity
  • Multi-Region, multi-active apps using global tables
AWS docs

Which one does the question want?

If the question saysPickWhy
A relational database on MySQL or PostgreSQL that needs high availability and many read replicas with very low replica lagAuroraAurora Replicas share the same cluster volume, so a cluster can have up to 15 of them and lag is usually well under 100 milliseconds. Docs
A relational database that must run Oracle, SQL Server or Db2RDSAurora is only MySQL and PostgreSQL compatible. RDS supports Db2, MariaDB, SQL Server, MySQL, Oracle and PostgreSQL. Docs
Key-value lookups with consistent single-digit millisecond latency and no servers to manageDynamoDBDynamoDB is serverless and has no maintenance windows or versions to manage. Docs
Complex joins and multi-table SQL queries over structured dataRDSDynamoDB has no JOIN operator, so joins point you to a relational database. A standard RDS instance is the default choice when you do not need Aurora features. Docs
A relational database with unpredictable load that should scale its capacity automaticallyAuroraAurora Serverless adjusts capacity based on demand and is aimed at variable and unpredictable workloads. Docs
A globally distributed app that needs low-latency reads in other Regions from a relational databaseAuroraAn Aurora global database has one primary Region and up to 10 read-only secondary Regions, with replication typically under a second. Docs
A multi-Region, multi-active database where every Region accepts writesDynamoDBGlobal tables replicate changes between replica tables in different Regions, and a change in any replica is copied to all the others. Docs
Microsecond read latency in front of a NoSQL table, with minimal code changesDynamoDBDAX is a DynamoDB-compatible, API-compatible cache that brings eventually consistent reads from milliseconds down to microseconds. Docs

DynamoDB vs RDS

DynamoDB is a serverless NoSQL database for key-value and document data: there are no servers, versions or maintenance windows, and it keeps single-digit millisecond performance at any scale. It has no JOIN operator, so you design tables around known access patterns. Amazon RDS runs a relational engine (such as MySQL, PostgreSQL, MariaDB, Oracle, SQL Server or Db2) on DB instances that you choose and size, so you keep SQL, joins and constraints.

If the question stresses massive scale, unpredictable traffic, simple lookups by key or no servers to manage, pick DynamoDB. If it needs joins, ad hoc SQL or an existing relational application, pick RDS (or Aurora when it adds high performance on MySQL or PostgreSQL).

AspectDynamoDBRDS
Data model NoSQL: key-value and document itemsRelational tables queried with SQL
Queries By key and index; no JOIN operator, so you denormalizeJoins, ad hoc queries and constraints
Servers Serverless: nothing to provision, patch or upgradeYou choose and size DB instances; AWS handles backups, patching and failure recovery
Scaling On-demand mode scales automatically and you pay per request; provisioned mode for steady trafficChange the instance class, and add read replicas yourself
High availability Built in: data is copied across three Availability Zones by defaultTurn on a Multi-AZ deployment for a standby in another Availability Zone
Multi-Region Global tables: multi-active replication across RegionsCross-Region read replicas
Size limit exams test 400 KB maximum item sizeStorage per DB instance, with a maximum that depends on engine and storage type

Side by side

AspectAuroraRDSDynamoDB
Data model Relational, MySQL and PostgreSQL compatibleRelational, with a choice of six enginesNoSQL, key-value and document
Management model Managed through RDS. You pick DB instances (or serverless capacity) in a clusterManaged through RDS. You choose and size DB instances, and AWS handles backups, patching and failure recoveryServerless. No servers, versions or maintenance windows to manage
Storage and growth Cluster volume copied across three Availability Zones, grows automatically (up to 256 TiB on current engine versions)You provision storage per DB instance. Storage autoscaling can grow it for youTables of virtually any size, with no storage to provision
Scaling reads Up to 15 Aurora Replicas sharing one storage volume. Aurora Auto Scaling can add or remove themRead replicas you create yourself, using asynchronous replication. RDS does not autoscale themAdd read capacity with on-demand or provisioned mode, or add DAX for cached reads
High availability Aurora Replicas in other AZs act as failover targets, and the cluster volume already keeps copies in three AZsMulti-AZ DB instance deployment: one standby that provides failover but serves no reads. Multi-AZ DB cluster deployment: two standbys that provide failover and also serve readsBuilt in. Data is automatically replicated across three AZs, with a 99.99% availability SLA (99.999% with global tables)
Pricing model DB instance (or serverless capacity) plus storage, with Standard or I/O-Optimized configurationsDB instance hours plus provisioned storage, backup storage and data transfer, with on-demand or reserved optionsPay per request in on-demand mode, or pay for provisioned capacity per hour
Consistency Replicas read the same cluster volume, so they return the same data with minimal lag (usually well under 100 ms)Read replicas are updated asynchronously, so they can return slightly stale dataEventually consistent reads by default, strongly consistent reads optional (not on GSIs)
Multi-Region Aurora Global Database: one primary Region, up to 10 secondary RegionsCross-Region read replicasGlobal tables: multi-active, multi-Region replication
Read replica limit Up to 15 Aurora Replicas per cluster, and this quota cannot be raised15 read replicas per source DB instance by default, an adjustable quotaNo read replicas to manage. Add global tables or DAX for more read reach
Size limits exams like to test Cluster volume up to 256 TiB on current engine versions (128 TiB on older ones)Storage is allocated per DB instance, and the maximum depends on the engine and storage type400 KB maximum item size, including attribute names and values
Typical use Business-critical relational apps that need performance and fast failoverExisting apps that need a specific engine, or standard relational workloadsShopping carts, gaming state and leaderboards, and media metadata with known access patterns

Exam traps

  • Aurora is not a separate product from RDS.

    Aurora is part of Amazon RDS. You create it through RDS and it shares many management features. Still, the RDS User Guide covers engines other than Aurora, so exam wording like "RDS or Aurora" is asking about standard RDS engines versus the Aurora engine.

    AWS docs

  • A Multi-AZ standby is for availability, not for read scaling.

    In a Multi-AZ DB instance deployment the standby does not serve read traffic. If the question asks for read scaling, think read replicas, a Multi-AZ DB cluster deployment (its two standbys also serve reads) or Aurora Replicas.

    AWS docs

  • DynamoDB cannot do JOINs.

    If a scenario needs complex joins or ad hoc relational queries, DynamoDB is the wrong answer. DynamoDB wants you to denormalize data around known access patterns.

    AWS docs

  • Strongly consistent reads do not work on a global secondary index, and DAX serves eventually consistent data.

    All reads from GSIs and streams are eventually consistent. DAX is also aimed at eventually consistent reads, so it is not the fix when a question demands the latest data on every read.

    AWS docs

  • RDS read replicas do not scale automatically.

    You must create RDS read replicas yourself and RDS does not add or remove them as demand changes. For automatic scaling on a relational database, look at Aurora Auto Scaling (which adds or removes Aurora Replicas), Aurora Serverless, or RDS storage autoscaling (which only grows storage).

    AWS docs

Practice it

9 SAA-C03 database questions

Frequently Asked Questions

What is the difference between Aurora and RDS?

Aurora is a database engine inside the RDS family that is compatible with MySQL and PostgreSQL, while the other RDS engines run standard database software on a DB instance. Aurora stores data in a shared cluster volume spread across three Availability Zones, which affects replicas and failover. RDS also offers Oracle, SQL Server, MariaDB and Db2, which Aurora does not.

Aurora vs RDS: which should I pick on the exam?

If the question stresses high performance, many low-lag read replicas, fast failover or cross-Region reads on MySQL or PostgreSQL, pick Aurora. If it needs another engine such as Oracle or SQL Server, or just a standard managed relational database, pick RDS.

DynamoDB vs RDS: when is DynamoDB the better choice?

Pick DynamoDB when the data is key-value or document style, access patterns are known, and you want consistent low latency at any scale without managing servers. Pick RDS when you need joins, relational constraints or an existing SQL application.

Does DynamoDB support transactions?

Yes. DynamoDB transactions give you ACID guarantees across one or more tables in a single request. There is no extra cost to turn them on. You pay for the reads and writes in the transaction, and each transactional read or write uses twice the capacity units of a standard one.

How do DynamoDB capacity modes differ?

On-demand mode charges per request, scales automatically and needs no capacity planning. It is the default and the recommended choice for most workloads, including spiky or unpredictable ones. Provisioned mode charges for the read and write capacity you set per hour, so it suits steady workloads with forecastable demand.