RDS vs Aurora: 2026 Decision

Aurora is faster, more durable, more expensive. The decision rule based on workload and the cases where RDS still wins.

When Aurora wins

The choice between RDS and Aurora is one of the foundational AWS database decisions. Both are managed services running MySQL or PostgreSQL. Aurora is AWS's purpose-built database with custom storage; RDS runs the standard open-source engine on managed infrastructure. The decision is per-workload; neither is universally better.

What Aurora wins:

• High-throughput OLTP.: Aurora's custom storage layer is faster than vanilla MySQL or PostgreSQL on the same hardware. Workloads with high transaction throughput benefit; the storage layer is the bottleneck Aurora removes.
• Aurora's storage layer outperforms vanilla MySQL/Postgres.: The storage is a 6-way replicated, log-structured store that handles writes more efficiently than traditional engines. The performance benefit is real and measurable; it shows up in benchmarks and production workloads.
• Multi-region durability matters.: Aurora Global Database provides cross-region replication with under-second lag. Disaster recovery and global read scaling are first-class features. RDS multi-region is more limited.
• Aurora Global Database is mature.: The feature has been production for years; the operational story is well-understood; failover is reliable. Workloads with multi-region requirements benefit significantly.
• Read scaling.: Aurora supports up to 15 read replicas with low replication lag. Read-heavy workloads scale beautifully; the replicas share the same storage layer so the lag is minimal.

Aurora is the right choice when its specific advantages match the workload's needs. The premium price is justified by the capabilities.

When RDS wins

RDS is the simpler, cheaper option. For workloads that do not need Aurora's specific advantages, RDS provides solid managed databases at lower cost. The decision often comes down to cost vs Aurora's capabilities.

• Tight cost constraints.: RDS is cheaper at the same instance class. The compute pricing is lower; the storage pricing is lower; the per-GB I/O cost is lower. Cost-sensitive workloads benefit.
• RDS is cheaper at the same instance class.: A db.r6i.large RDS instance costs less than a db.r6i.large Aurora instance. The difference can be 20% or more depending on configuration. For workloads that do not need Aurora's specific features, the cost difference is real.
• Specific Postgres extension needs.: PostgreSQL has many extensions (PostGIS, TimescaleDB, pgvector, others). Aurora supports a subset; RDS supports more. Workloads that require unsupported extensions need RDS.
• Aurora supports a subset.: The list of supported extensions on Aurora is smaller than on RDS. Some popular extensions are missing; planning database choices around extension needs prevents migration regret.
• MySQL or Postgres versions newer than Aurora.: RDS often supports newer versions of MySQL and PostgreSQL faster than Aurora. Teams that need the latest features may need RDS.

RDS is the right choice when Aurora's specific advantages do not apply. The simpler, cheaper option fits many workloads.

Aurora Serverless

Aurora Serverless is a third option: Aurora that scales compute capacity automatically based on load. The pricing model is per-ACU-hour rather than per-instance; the capacity matches actual demand.

• Bursty, low-volume workloads.: Workloads with intermittent usage benefit. Dev environments, batch jobs that run hourly, internal tools used during business hours. The serverless model matches the workload pattern.
• Auto-scales to zero between bursts.: Aurora Serverless v2 scales down to a minimum (0.5 ACU is the floor); idle workloads cost much less than provisioned alternatives. The savings on idle workloads can be substantial.
• Cost: scale-to-zero is real.: Workloads that are idle most of the time pay only for active periods plus the minimum capacity. The cost can be 80% lower than equivalent provisioned Aurora.
• Cold-start latency is meaningful.: Scaling up from minimum capacity takes time; the first requests after idle periods are slower. Workloads with strict latency requirements may not tolerate the cold-start.
• v2 is the production answer.: Aurora Serverless v1 had significant operational limitations; v2 addresses most of them. Production workloads should use v2; v1 is mostly deprecated.

RDS vs Aurora decision is one of the most consequential AWS database choices. Nova AI Ops integrates with database telemetry, surfaces patterns that suggest one option over another, and helps teams understand whether their current choice is producing the expected value.