Aurora vs RDS
Decision criteria.
Overview
Aurora and RDS are AWS's managed relational database services with overlapping but distinct profiles. RDS is the broad managed-database service supporting standard engines (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server); Aurora is the Amazon-built MySQL- and PostgreSQL-compatible engine with a rebuilt storage layer. Pick by scale and read-replica requirements; cost favours RDS at small scale, Aurora at large.
- RDS: standard engines. MySQL, PostgreSQL, MariaDB, Oracle, SQL Server. Default when standard engine behaviour or non-MySQL/Postgres engines matter.
- Aurora: AWS-native engine. MySQL/PostgreSQL-compatible with rebuilt storage layer. Default when scale or replica count matters.
- Storage and replicas favour Aurora. Auto-expanding to 128 TB across six copies in three AZs; up to 15 read replicas with low lag. Wins for large or read-heavy workloads.
- Cost favours RDS at small scale. Aurora's per-instance and IO billing exceeds RDS at modest workloads. Match cost model to actual scale.
The approach
RDS by default, Aurora when scale or replica count makes the case. Aurora Serverless for spiky workloads where compute should scale automatically. Document the choice per database so the rationale survives the original engineer.
- RDS for small to medium workloads. Most workloads fit RDS comfortably. Simple operations.
- Aurora for read-heavy or large data. Many read replicas with low lag, storage scaling without manual ops. Default when scale drives the choice.
- Aurora Serverless for variable load. Auto-scaling compute. Matches spiky workloads where reserved capacity wastes spend.
- Documented choice per database. Per-database rationale captured. Supports future review.
Why this compounds
The right engine choice compounds across years. Wrong engines pay performance or cost penalties indefinitely; right engines pay neither. Cross-database tooling (failover, backup strategy, capacity planning) gets built once per engine and reused. By year two the engine choice is automatic per database.
- Better performance. Right engine for the workload. Queries stay fast as data grows.
- Better cost. Engine matches budget envelope. Real savings at the wrong-scale-default trap.
- Better operational fit. Aurora's failover speed vs RDS's familiarity. Match operational model to team expertise.
- Year-one investment, year-two habit. First year builds patterns; subsequent decisions run on the same rationale.