When a team decides to move its database to AWS, the question comes up almost immediately: Amazon RDS or Amazon Aurora? Both are managed relational databases, both free your team from patching servers and managing backups, and both live side by side in the console. The difference is not “which one is better” but which problem each one solves — and choosing without criteria gets paid for later, in cost, in availability, or in a modernization that becomes harder.
This guide compares both options with decision criteria for technology leaders, not just DBAs.
What each one is, in a sentence
- Amazon RDS (Relational Database Service) is AWS’s managed service for running well-known database engines: PostgreSQL, MySQL, MariaDB, SQL Server, Oracle and Db2. The engine is the same one you would run on your own server; AWS operates the infrastructure.
- Amazon Aurora is a database engine built by AWS, compatible with PostgreSQL and MySQL, with a different storage architecture: data is replicated in six copies across three Availability Zones, and storage grows automatically with usage.
The confusion is understandable: Aurora is managed from within RDS and shares most day-to-day operations. But underneath they are different architectures, and that difference is what decides.
The criteria that actually decide
1. The engine your application needs
This criterion filters before any other. If your application runs on SQL Server, Oracle, Db2 or MariaDB and changing it is not in your plans, the decision is already made: Amazon RDS is the managed path for those engines. Aurora only speaks PostgreSQL and MySQL.
The important exception is SQL Server, because there is a third way: Babelfish for Aurora PostgreSQL, a capability included with Aurora that understands T-SQL and SQL Server’s wire protocol. With Babelfish, many applications written for SQL Server can connect to Aurora PostgreSQL with minimal changes — and that path turns a technical decision into a financial one, because commercial licensing stops growing with your business. At Caleidos it is one of the modernization routes we evaluate most.
2. Availability: what a minute of downtime costs you
RDS solves high availability with Multi-AZ deployments: a standby instance in another Availability Zone that takes over if the primary fails, with a failover that typically takes one to two minutes.
Aurora starts from a different foundation: since storage already lives replicated in six copies across three zones, replicas share the same data volume and typical failover takes under a minute — with replicas available, it often drops below 30 seconds. It also supports up to 15 low-lag read replicas, which double as failover targets.
For an internal system that can tolerate a short pause, Multi-AZ on RDS is sufficient and simpler. For a digital channel where every minute down is lost revenue — banking, retail, payments —, Aurora’s architecture earns its place.
3. Performance and workload pattern
AWS documents that Aurora can deliver up to five times the throughput of standard MySQL and up to three times that of standard PostgreSQL on equivalent hardware. If your database is already close to its instance limit on RDS, Aurora is the natural growth path before sharding or redesigning.
The workload pattern matters too: for variable or unpredictable demand — seasonal spikes, multi-tenant platforms, growing products —, Aurora Serverless v2 adjusts capacity automatically and in fine-grained increments, avoiding payment for idle capacity. RDS, by contrast, is sized per instance: simple and predictable for flat workloads.
4. Cost: unit price vs the cost of the full workload
Comparing the hourly price of an Aurora instance against its RDS equivalent leads to an incomplete conclusion. Aurora usually costs more per instance, but it delivers more performance per instance, scales storage without over-provisioning, and its replicas do not duplicate the data volume. For read/write-intensive workloads, the Aurora I/O-Optimized configuration removes per-I/O charges and makes cost predictable.
The right comparison is the total cost of your workload at the availability level your business requires — and that math changes case by case. It is the same approach we apply in FinOps: measure on the real workload, not on the price list.
Aurora vs RDS: the decision table
| Criterion | Amazon RDS | Amazon Aurora |
|---|---|---|
| Engines | PostgreSQL, MySQL, MariaDB, SQL Server, Oracle, Db2 | Compatible with PostgreSQL and MySQL |
| High availability | Multi-AZ, typical failover 1–2 minutes | 6 copies across 3 zones, typical failover < 1 minute |
| Read replicas | Replicas with their own copy of the data | Up to 15 replicas on the same volume |
| Storage | Provisioned and adjusted | Grows automatically with usage |
| Scaling on demand | By changing instance size | Fine-grained, automatic Serverless v2 |
| Path from SQL Server | Native SQL Server engine (commercial license) | Babelfish: T-SQL on PostgreSQL |
| Typical profile | Steady workloads, commercial engines, simplicity | High throughput, demanding availability, variable demand |
When each one fits
Choose Amazon RDS when your workload is steady and moderately sized, when you depend on an engine Aurora does not support (SQL Server, Oracle, Db2, MariaDB) with no plans to change it, or when predictability and operational simplicity matter more than peak performance.
Choose Amazon Aurora when availability is business-critical, when your database throughput is already a constraint, when your demand is variable and Serverless v2 avoids idle capacity, or when you want to leave SQL Server licensing behind using Babelfish as a modernization door.
And remember it is not an irreversible decision: if you are on RDS with MySQL or PostgreSQL today, the road to Aurora is paved — a snapshot or a replica that gets promoted, without rewriting the application.
How we approach it at Caleidos
At Caleidos, as an AWS Advanced Tier Services Partner, this decision is part of our data and analytics and modernization practices: we size the real workload, calculate the total cost of each scenario at the availability level the business requires, and when commercial licensing is involved we evaluate Babelfish and conversion paths before accepting that cost as fixed. If you want to understand the technology foundation first, we go deeper in Amazon RDS.
Evaluating where to run your database on AWS?
Let’s talk about your case: in 30 minutes we will give you a concrete read on whether your workload fits better on RDS, on Aurora, or on a modernization path with Babelfish.
