Amazon RDS vs Amazon Aurora
A comparison of Amazon RDS and Amazon Aurora built from values read directly from each provider's own documentation, with the source recorded against every figure.
The short answer
- Pick Amazon RDS if
- Teams already inside AWS, where the database sitting in the same VPC as everything else is worth more than any single feature on this page. Six engines, up to 35 days of point-in-time recovery, and read replicas you create and delete yourself.
- Pick Amazon Aurora if
- Teams on AWS who want a Postgres or MySQL cluster that can throw off a copy-on-write clone of production in minutes, keep up to fifteen readers behind it, and pause to nothing between bursts in serverless mode.
3 sourced criteria separate them:
- Engine
- Amazon RDS: PostgreSQL, alongside MySQL, MariaDB, Oracle, SQL Server and Db2. Each engine is a separate RDS product with its own version list and its own feature support, so a capability documented for one is not a capability of RDS as a whole.
- Amazon Aurora: MySQL- and PostgreSQL-compatible. Aurora is AWS's own engine rather than a hosted build of either, so compatibility is the claim being made — existing code, tools and applications are stated to work, which is not the same as being the upstream database.
- Point-in-time recovery
- Amazon RDS: Any point inside the configured backup retention period, so up to 35 days. Transaction logs are uploaded to S3 every five minutes, which is what bounds how close to now the latest restorable time can be.
- Amazon Aurora: Any point inside the backup retention period, so up to 35 days. Aurora's backups are continuous and incremental against the cluster volume rather than periodic snapshots plus log replay, which is why AWS states no performance impact while they are taken.
- Backup retention
- Amazon RDS: Between 0 and 35 days, set per DB instance; 0 disables automated backups entirely. The default depends on how the instance was created — one day via the API or CLI, seven days via the console — so there is no single default to quote. Multi-AZ DB clusters cannot be set below 1 day.
- Amazon Aurora: 1 to 35 days. Unlike an RDS DB instance it cannot be set to 0 — Aurora backs the cluster volume up continuously and there is no way to turn that off.
Pick the criteria you care about. The chart counts how many of them lean toward each provider — the same read as scanning the bars below, just totalled for the ones you chose.
Amazon RDS 0
Amazon Aurora 0
At a glance.
| Criterion | Amazon RDS | Amazon Aurora |
|---|---|---|
| Data | ||
| Engine | PostgreSQL, alongside MySQL, MariaDB, Oracle, SQL Server and Db2. Each engine is a separate RDS product with its own version list and its own feature support, so a capability documented for one is not a capability of RDS as a whole. | MySQL- and PostgreSQL-compatible. Aurora is AWS's own engine rather than a hosted build of either, so compatibility is the claim being made — existing code, tools and applications are stated to work, which is not the same as being the upstream database. |
| Point-in-time recovery | Any point inside the configured backup retention period, so up to 35 days. Transaction logs are uploaded to S3 every five minutes, which is what bounds how close to now the latest restorable time can be. | Any point inside the backup retention period, so up to 35 days. Aurora's backups are continuous and incremental against the cluster volume rather than periodic snapshots plus log replay, which is why AWS states no performance impact while they are taken. |
| Read replicas | Supported — 15 per primary, raisable on request | Supported — 15 per cluster, a quota AWS will not raise |
| Backup retention | Between 0 and 35 days, set per DB instance; 0 disables automated backups entirely. The default depends on how the instance was created — one day via the API or CLI, seven days via the console — so there is no single default to quote. Multi-AZ DB clusters cannot be set below 1 day. | 1 to 35 days. Unlike an RDS DB instance it cannot be set to 0 — Aurora backs the cluster volume up continuously and there is no way to turn that off. |
Where they differ.
Engine
- Amazon RDS
- PostgreSQL, alongside MySQL, MariaDB, Oracle, SQL Server and Db2. Each engine is a separate RDS product with its own version list and its own feature support, so a capability documented for one is not a capability of RDS as a whole.
- Amazon Aurora
- MySQL- and PostgreSQL-compatible. Aurora is AWS's own engine rather than a hosted build of either, so compatibility is the claim being made — existing code, tools and applications are stated to work, which is not the same as being the upstream database.
Sources (2) →Sources ↓
- Amazon RDS for PostgreSQL — Amazon Relational Database Service User Guide ↗
“Amazon RDS supports DB instances running several versions of PostgreSQL. [...] DB instances running PostgreSQL support Multi-AZ deployments, read replicas, Provisioned IOPS, and can be created inside a virtual private cloud (VPC).”
Read 2026-09-09 · official docs
- What is Amazon Aurora? — Amazon Aurora User Guide ↗
“Amazon Aurora (Aurora) is a fully managed relational database engine that's compatible with MySQL and PostgreSQL. [...] The code, tools, and applications you use today with your existing MySQL and PostgreSQL databases can be used with Aurora.”
Read 2026-09-09 · official docs
Point-in-time recovery
Any point inside the configured backup retention period, so up to 35 days. Transaction logs are uploaded to S3 every five minutes, which is what bounds how close to now the latest restorable time can be.
Any point inside the backup retention period, so up to 35 days. Aurora's backups are continuous and incremental against the cluster volume rather than periodic snapshots plus log replay, which is why AWS states no performance impact while they are taken.
Sources (2) →Sources ↓
- Restoring a DB instance to a specified time for Amazon RDS — Amazon Relational Database Service User Guide ↗
“RDS uploads transaction logs for DB instances to Amazon S3 every five minutes. To see the latest restorable time for a DB instance, use the AWS CLI describe-db-instances command and look at the value returned in the LatestRestorableTime field for the DB instance. [...] You can restore to any point in time within your backup retention period.”
Read 2026-09-09 · official docs
- Backing up and restoring an Aurora DB cluster — Amazon Aurora User Guide ↗
“Aurora automated backups are continuous and incremental, so you can quickly restore to any point within the backup retention period. No performance impact or interruption of database service occurs as backup data is being written.”
Read 2026-09-09 · official docs
Backup retention
- Amazon RDS
- Between 0 and 35 days, set per DB instance; 0 disables automated backups entirely. The default depends on how the instance was created — one day via the API or CLI, seven days via the console — so there is no single default to quote. Multi-AZ DB clusters cannot be set below 1 day.
- Amazon Aurora
- 1 to 35 days. Unlike an RDS DB instance it cannot be set to 0 — Aurora backs the cluster volume up continuously and there is no way to turn that off.
Sources (2) →Sources ↓
- Backup retention period — Amazon Relational Database Service User Guide ↗
“If you create a DB instance using the Amazon RDS API or the AWS CLI and if you don't set the backup retention period, the default backup retention period is one day. If you create a DB instance using the console, the default backup retention period is seven days. [...] You can set the backup retention period of a DB instance to between 0 and 35 days. Setting the backup retention period to 0 disables automated backups. For a Multi-AZ DB cluster, you can set the backup retention period to between 1 and 35 days.”
Read 2026-09-09 · official docs
- Backing up and restoring an Aurora DB cluster — Amazon Aurora User Guide ↗
“Aurora backs up your cluster volume automatically and retains restore data for the length of the backup retention period. [...] You can specify a backup retention period from 1–35 days when you create or modify a DB cluster.”
Read 2026-09-09 · official docs
When these numbers change, hear about it. Sources are re-checked monthly; a repricing goes out as a short note.
Which should you choose?
Choose Amazon RDS if…
Teams already inside AWS, where the database sitting in the same VPC as everything else is worth more than any single feature on this page. Six engines, up to 35 days of point-in-time recovery, and read replicas you create and delete yourself.
Editorial · Palash Bagchi · approved
Choose Amazon Aurora if…
Teams on AWS who want a Postgres or MySQL cluster that can throw off a copy-on-write clone of production in minutes, keep up to fifteen readers behind it, and pause to nothing between bursts in serverless mode.
Editorial · Palash Bagchi · approved
Consider something else if…
- Amazon RDS: You want a database per pull request. RDS documents no branching, and replicas are manual — AWS states outright that it does not autoscale them.
- Amazon Aurora: You want the upstream database rather than a compatible one, or a branch workflow rather than a clone. AWS documents cloning as a way to build a test environment, not as something you do per pull request.
Documented by only one.
These criteria are published by one provider and not the other. An absence here means we have not found a source, not that the feature is missing.
Questions this comparison answers.
Should I choose Amazon RDS or Amazon Aurora?
Pick Amazon RDS if Teams already inside AWS, where the database sitting in the same VPC as everything else is worth more than any single feature on this page. Six engines, up to 35 days of point-in-time recovery, and read replicas you create and delete yourself.
Pick Amazon Aurora if Teams on AWS who want a Postgres or MySQL cluster that can throw off a copy-on-write clone of production in minutes, keep up to fifteen readers behind it, and pause to nothing between bursts in serverless mode.