RDS or Aurora? Picking the right AWS database without overpaying

Three buttons in the AWS console will run your Postgres or MySQL, and they look almost interchangeable: RDS, Aurora, and Aurora Serverless v2. They are not. Pick wrong and you either pay a premium every month for capability you never use, or you save a little now and discover at the worst moment that your failover takes two minutes instead of thirty seconds. The right choice is not the most powerful one; it is the one that matches how your traffic actually behaves.

The three options, plainly

Start with what each one is, without the marketing. RDS is managed standard database software - the same Postgres or MySQL you would run yourself, but with backups, patching, and Multi-AZ standby handled by AWS. The storage underneath is ordinary block storage you provision.

Aurora keeps the Postgres or MySQL interface but replaces the storage engine with a distributed layer that copies your data six ways across three availability zones. That is what gives Aurora its faster failover and its read replicas that all share one storage volume. Aurora Serverless v2 is Aurora with the capacity managed for you - instead of choosing an instance size, you set a floor and ceiling and it scales between them automatically as load changes. Same engine, different billing and scaling model.

How they really differ

Three differences carry the decision: cost model, scaling, and failover.

• Cost model. RDS bills you for the instance plus the storage you provision. Aurora's instances cost more per hour, storage grows automatically so you never over-provision it, but you also pay for I/O unless you choose the I/O-Optimized tier. On a read-heavy app the I/O line can surprise you, which is exactly the kind of bill we hunt down in our AWS cost optimization tips.
• Scaling reads. RDS read replicas each copy the full dataset and lag a little. Aurora replicas read from the same shared storage, so they spin up faster, lag less, and scale to more of them. If your load is mostly reads, this is Aurora's strongest argument.
• Failover. RDS Multi-AZ promotes a standby on failure, typically in a minute or two. Aurora usually fails over in well under a minute because the storage is already shared and replicated. For a checkout flow or any revenue-critical path, that gap is the difference between a blip and a visible outage.

Notice none of these is "Aurora is better". Each is a trade you make for a price. A small, steady internal app gains nothing from six-way storage replication and pays more for it. A high-traffic storefront with heavy read load and zero tolerance for downtime gets real value from exactly those features.

Aurora Serverless v2: when autoscaling helps and when it stings

Serverless v2 is the option teams most often misuse. It scales capacity up and down in fine increments measured in Aurora Capacity Units, so it shines when load is genuinely variable - a workload that is quiet overnight and busy by day, a dev environment, or an app with unpredictable spikes. You stop paying for a large instance that sits mostly idle.

The sting comes when people reach for Serverless to "not think about sizing" on a workload that is actually steady and high. If your database runs near a constant high load all day, Serverless can cost more than a right-sized provisioned Aurora or RDS instance, because the per-capacity price is set for flexibility, not for sustained heavy use. There is also a minimum capacity floor you pay for even at idle. Serverless rewards variability and penalizes flat, predictable demand - the opposite of what most teams assume.

Which to pick for which workload

Map it to your situation rather than a feature chart. Choose RDS when your workload is steady and predictable, your budget is tight, and you value being able to lift the same Postgres or MySQL elsewhere later. It is the sensible default for a great many applications, and the one people skip past too quickly.

Choose provisioned Aurora when you have high, sustained traffic, a read-heavy pattern that benefits from several fast replicas, and a low tolerance for downtime that makes sub-minute failover worth paying for. Choose Aurora Serverless v2 when your load genuinely swings - daily peaks and troughs, seasonal spikes, or environments that should scale to near zero when nobody is using them. When the pattern is mixed, a common and sound setup is provisioned Aurora for the steady baseline with Serverless for variable secondary workloads. Picking the right shape here is the same discipline we bring to any managed cloud services engagement.

Migration and lock-in

One quiet factor deserves a seat at the table: portability. Plain RDS runs standard Postgres or MySQL, so moving to another host or back on-prem later is comparatively straightforward. Aurora and Serverless are AWS-only; you keep the SQL interface, but the engine underneath ties you to AWS. That is a fair trade for the performance and uptime if you are committed to AWS, but it should be a conscious choice, not a default. If you are weighing a move between tiers or off ordinary instances, that planning is part of our AWS consulting services, and it pairs naturally with right-sizing the compute around it, as in our Graviton migration cost guide.

Frequently asked questions

Is Aurora always faster than RDS?

Not always. Aurora often wins on read scaling and failover speed, but for a modest, steady single-instance workload a well-configured RDS instance performs perfectly well at lower cost. "Faster" depends on whether your workload uses the features you are paying Aurora for.

Does Aurora Serverless scale to zero?

Aurora Serverless v2 scales down to a low minimum capacity you configure, not fully to zero, so you pay a floor even when idle. Set that floor as low as your cold-start tolerance allows so quiet periods stay cheap without hurting first-request latency.

What is the I/O charge people warn about on Aurora?

Standard Aurora bills for read and write I/O operations on top of compute and storage, which can dominate the bill on I/O-heavy workloads. If your app does heavy I/O, the I/O-Optimized pricing tier swaps that variable charge for a flat rate that is often cheaper at scale - model both before committing.

Can I switch from RDS to Aurora later?

Yes. AWS supports migrating an existing RDS Postgres or MySQL database to Aurora, often with minimal downtime using a replica-and-promote approach. Starting on RDS and moving to Aurora when your scale justifies it is a perfectly reasonable path.

The short version: there is no best database here, only a best fit. Look at how your traffic actually behaves - steady or spiky, read-heavy or balanced, downtime-tolerant or not - and let that shape pick the option. The most expensive mistake is reaching for the most powerful tier out of caution and paying for it every month for capability your workload never touches.