# Amazon RDS vs Amazon Aurora

Canonical: https://inetgeek.com/compare/amazon-rds-vs-amazon-aurora/

Every value below is read from Amazon RDS's and Amazon Aurora's own documentation. See https://inetgeek.com/methodology/ for how.

## At a glance

| Criterion | Amazon RDS | Amazon Aurora |
| --- | --- | --- |
| 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. ([source](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html))
- 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. ([source](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_AuroraOverview.html))

### 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. ([source](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIT.html))
- 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. ([source](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.Backups.html))

### 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. ([source](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.BackupRetention.html))
- 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. ([source](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.Backups.html))

## Which should you choose?

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.

Consider something else: 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.

Consider something else: 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

- Free tier: Amazon Aurora: Yes — capped Free plan plus time-limited credits
- Pricing model: Amazon Aurora: Pay per use with no plan fee: instances plus storage plus I/O, or ACU-hours in serverless mode. AWS's own worked example prices serverless compute at $0.12 per ACU-hour on Aurora Standard and $0.156 on Aurora I/O-Optimized in US East (N. Virginia) — the difference being whether I/O is metered separately or folded into a higher compute and storage rate. Provisioned instances also offer Reserved Instance pricing, and usage may qualify for Database Savings Plans against a committed hourly spend.
- Managed connection pooling: Amazon RDS: Supported
- Scales to zero: Amazon Aurora: Supported — serverless capacity mode only
- Regions: Amazon Aurora: 34 AWS regions, the same list for the MySQL- and PostgreSQL-compatible editions. Counted from the two availability tables in Aurora's own docs, which publish the regions and no total.
- Connection limit: Amazon RDS: Not a fixed number: RDS for PostgreSQL sets max_connections by formula from the instance's memory — LEAST({DBInstanceClassMemory/9531392}, 5000) — so a bigger instance class gets more connections and the ceiling is 5,000 however large it is. The parameter can be set by hand anywhere from 6 to 262,143, which is a limit on what you may configure rather than what an instance will serve. Other engines use different divisors: MySQL is memory/12582880 with no cap.
- Database branching: Amazon Aurora: Limited — clones, not a branch workflow
- Rewind in place: Amazon Aurora: Limited — Aurora MySQL edition only

## 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.