Overview
Pick RDS for PostgreSQL for most workloads; pick Aurora PostgreSQL when failover time, read scale-out, serverless scaling, or cross-Region replication justifies the higher price. RDS runs the community engine. Aurora keeps the Postgres front end but replaces storage with a shared cluster volume replicated across three Availability Zones, and has two storage billing configurations (Standard and I/O-Optimized).
Comparison
| Dimension | RDS for PostgreSQL | Aurora PostgreSQL |
|---|---|---|
| Engine | Community Postgres | Postgres-compatible with a custom storage layer |
| Storage | Provisioned volume per instance | Shared cluster volume, grows automatically up to 256 TiB on supported engine versions |
| HA options | Multi-AZ DB instance (one standby, not readable) or Multi-AZ DB cluster (two readable standbys, semi-synchronous) | Failover to an Aurora Replica; typically restored in under 60 seconds, often under 30 |
| Read scale | Read replicas, each with its own storage | Up to 15 Aurora Replicas on the shared volume |
| Serverless | Not available | Aurora serverless scales in 0.5 ACU steps and can scale to zero with auto-pause |
| Cross-Region | Cross-Region read replicas | Aurora Global Database (asynchronous replication) |
| I/O billing | Included in volume pricing | Standard bills per I/O request; I/O-Optimized bills none |
Pick RDS when
Pick RDS when you want community Postgres at lower cost and fewer surprises.
- Steady workloads where a right-sized instance is cheaper than Aurora.
- Extensions, replication slots, vacuum, and
pg_statbehavior should match self-hosted Postgres; test any dependency on internals before moving to Aurora. - Multi-AZ DB cluster deployments give two readable standbys and faster failover than a single-standby instance, still on community Postgres.
- A portable path to self-hosting or another provider.
Pick Aurora when
Pick Aurora when availability, read fan-out, or elasticity is the requirement.
- A payment or core service that needs failover in well under a minute: run at least one replica in a second Availability Zone.
- Read-heavy workloads that need many low-lag readers via the reader endpoint. See read-replica.
- Spiky or idle-heavy workloads on Aurora serverless, including dev and test clusters that pause.
- Multi-Region disaster recovery or low-latency global reads with Global Database.
- I/O-Optimized when I/O is 25 percent or more of your Aurora spend, per AWS guidance; you can switch configurations (Standard to I/O-Optimized once every 30 days).
- Use RDS Proxy for pooling and to cut failover time on Aurora.
Neither fits large analytical scans; evaluate Amazon Redshift or a columnar store for those.
Migrate
RDS to Aurora is native: create an Aurora read replica from the RDS instance and promote it, or restore a snapshot into an Aurora cluster. Aurora to RDS has no snapshot path back; use pg_dump or logical replication. Before cutover, test autovacuum behavior, logical replication slots, and extension versions on Aurora. See postgres-replication and dynamodb-vs-postgres for the alternatives.
FAQ
Is Aurora PostgreSQL worth the extra cost over RDS?
Only when failover time, read scale-out, serverless scaling, or cross-Region replication justifies the higher price. For steady workloads a right-sized RDS for PostgreSQL instance is cheaper.
How fast does Aurora fail over?
Failover to an Aurora Replica is typically restored in under 60 seconds and often under 30. Run at least one replica in a second Availability Zone, and use RDS Proxy to cut failover time further.
How many read replicas can Aurora have?
Aurora supports up to 15 Aurora Replicas on the shared cluster volume. RDS read replicas each carry their own storage.
When should I use Aurora I/O-Optimized?
Use I/O-Optimized when I/O is 25 percent or more of your Aurora spend, per AWS guidance. You can switch from Standard to I/O-Optimized once every 30 days.
Can I move from Aurora back to RDS?
There is no snapshot path from Aurora back to RDS; use pg_dump or logical replication. RDS to Aurora is native through an Aurora read replica or a snapshot restore.