Among the engines offered by RDS, there is a special one created by AWS itself: Aurora. It is not a "factory" engine like MySQL or PostgreSQL, but an improved and reinvented version by AWS for the cloud. In this subchapter, we will see what makes it different and when to choose it over "classic" RDS (what is usually called vanilla RDS).

Amazon Aurora is a relational database created by AWS that is compatible with MySQL and PostgreSQL, but redesigned internally to make the most of the cloud.

• "Compatible with MySQL/PostgreSQL" means that your application talks to Aurora just as it would to MySQL or PostgreSQL. You don't have to rewrite your code or learn a new language. Under the hood, Aurora is very different and much more efficient.

Analogy: Imagine MySQL is a good street car. Aurora is like taking that same car, keeping the steering wheel and pedals (so you know how to drive it without learning anything new) but replacing the engine with a racing one. You drive the same, but it performs much better.

AWS claims that Aurora can be up to 5 times faster than MySQL and up to 3 times faster than PostgreSQL in standard RDS, thanks to its redesigned storage architecture. For demanding applications, this is a big difference.

In classic RDS, you have to decide in advance how much disk space to reserve (and expand it manually if you run out). In Aurora, storage grows automatically as your data increases, without you having to do anything. You pay for what you use.

Practical advantage: you forget about the classic scare of "the database disk is full." Aurora expands by itself.

Aurora automatically keeps six copies of your data spread across three availability zones. This makes it extremely resilient to failures: it can lose entire copies and keep running without losing data. Failover recovery is faster than in classic RDS.

Aurora allows up to 15 read replicas (compared to 5 in classic RDS) and with minimal synchronization lag. Ideal for applications with a lot of reads.

There is a variant called Aurora Serverless that automatically adjusts its capacity according to demand, and can even scale down to almost zero when there is no activity. You pay for actual usage.

When it's great: for applications with intermittent or unpredictable usage (for example, a development environment that is only used during office hours, or an app with sporadic spikes). Instead of paying for a database running 24/7, you pay only when it is used. Remember the spirit of elasticity from Chapter 1.

Not necessarily. Aurora is more powerful but also somewhat more expensive than vanilla RDS. The choice depends on your case:

Choose Aurora when:

• You need high performance or expect to grow a lot.
• You want maximum availability without complications.
• You have a heavy read load (take advantage of its replicas).
• Your usage is intermittent and you are interested in Aurora Serverless.

Choose vanilla RDS when:

• Your application is small or medium and doesn't need the extra performance.
• You want to minimize cost.
• You need an engine that Aurora doesn't offer (Oracle, SQL Server, MariaDB…).
• You want exactly the same "factory" MySQL/PostgreSQL for some specific requirement.

Real example: A startup launches its product with standard RDS PostgreSQL because it's cheap and sufficient. When its user base grows and the database starts to struggle with performance, they migrate to Aurora PostgreSQL (without touching their code, thanks to compatibility) and gain speed and scalability. Aurora "accompanies" their success.

• Aurora is AWS's own relational database, compatible with MySQL and PostgreSQL (your code works the same) but redesigned for the cloud.
• Its advantages: much higher performance, storage that grows automatically, superior high availability (6 copies in 3 AZ), more read replicas, and the Aurora Serverless option (auto-scaling, ideal for intermittent use).
• It is more powerful but somewhat more expensive than vanilla RDS.
• Choose Aurora for high performance/growth; vanilla RDS for smaller projects, lower cost, or engines that Aurora doesn't offer.

In the next subchapter, we switch worlds: we will look at DynamoDB, a NoSQL database very different from relational ones, and when it makes sense to use it.