Amazon RDS vs Aurora

Amazon RDS (Relational Database Service) and Amazon Aurora are both managed database services provided by Amazon Web Services (AWS), but they have some key differences. Here’s an overview of each:

Amazon RDS:

1. Database Engines: Amazon RDS supports multiple relational database engines, including MySQL, PostgreSQL, MariaDB, Oracle, and Microsoft SQL Server. This flexibility allows you to choose the database engine that best fits your application’s requirements.
2. Features: Amazon RDS provides a range of features, including automated backups, automated software patching, and high availability configurations. It simplifies database management tasks, making it easier for users who don’t want to deal with the administrative aspects of database maintenance.
3. Scalability: Amazon RDS allows you to scale your database vertically by adjusting the instance size or horizontally by adding read replicas. This helps in handling varying workloads and improving performance.
4. Ease of Use: Amazon RDS abstracts much of the underlying database administration tasks, making it easy to set up, operate, and scale databases. It provides a web-based management console and supports command-line tools for database management.

Amazon Aurora:

1. Database Engine: Amazon Aurora is a MySQL and PostgreSQL-compatible relational database engine. It is designed to offer high performance and availability with compatibility to existing MySQL and PostgreSQL applications, allowing for easy migration.
2. Performance: Aurora is known for its high performance. It is built with a distributed architecture that replicates data across multiple Availability Zones (AZs), providing fault tolerance and high availability. Aurora Replicas can be used to offload read traffic, improving overall performance.
3. Storage: Aurora uses a storage system that automatically divides your database volume into 10GB segments spread across many disks. Each 10GB chunk of your database volume is replicated six ways, across three Availability Zones. This contributes to both high performance and fault tolerance.
4. Scalability: Aurora allows for both vertical and horizontal scaling. It supports automatic and manual scaling of read replicas to handle read traffic. Aurora also provides the Aurora Global Database feature for cross-region replication.
5. Backups and Failover: Aurora provides continuous backups to Amazon S3 and supports point-in-time recovery. It also offers automated failover in case of a primary instance failure.

Key Differences:

1. Compatibility: Amazon RDS supports various database engines, while Aurora is specifically designed for MySQL and PostgreSQL compatibility.
2. Performance: Aurora is often considered to provide better performance compared to standard RDS instances, especially for read-heavy workloads.
3. Architecture: Aurora has a unique distributed architecture that contributes to its high performance and fault tolerance, whereas RDS follows a more traditional architecture for each supported database engine.

In summary, both Amazon RDS and Amazon Aurora are powerful managed database services, and the choice between them depends on your specific requirements, compatibility needs, and performance considerations. Aurora is a specialized solution for MySQL and PostgreSQL workloads that demand high performance, while RDS offers more flexibility in terms of supported database engines.

On a personal note

Instability under increased load is to be expected due to multiple factors. The applications and databases we investigated are not suitable for the platform of choice Amazon RDS Aurora. This DBaaS platform is recommended for its ease of deployment, fast failover and high performance. The price for those characteristics is increased latency on databases with secondary indexes. This could be addressed by migration to RDS MySQL, but in that case failover would typically be taking 60 to 120 seconds again. Of course, there are possibilities to mitigate those high failover times with multiple RDS cluster replicating to each other, but ultimately the choice for RDS was based on ease of use.

Amazon RDS Aurora is famous for its write performance compared to traditional Amazon RDS products. However, there must be a suitable use case for this scenario. For example, there should be certain tolerance for delay at a read replica. In case secondary indexes are added to the system for increased read performance the latency will rise considerably.

Some of the above is partly due to the fact that the engineers implementing Aurora had to disable the MySQL change buffer on which changes to secondary indexes heavy depends.

Amazon RDS Aurora Serverless was introduced to have a true pay-per-use implementation. Resources will automatically scale up and down on demand. It can be configured to go to sleep (pause) when idle. For development and testing environments this could be a great feature.  For this feature to work the inactivity has to be complete – even a single query or idle open connection will make a pause impossible.

We conducted a benchmark to investigate latency on RDS Aurora MySQL vs RDS MySQL. We used similar instance types and used the following table definition:

create table latency_test ( id int not null auto_increment, 
                            comments varchar (100), 
                            updated timestamp null, 
                            value int null, 
                            primary key (id));
create index pertest1 on latency_test (comments);
create index pertest2 on latency_test (updated);
create index pertest3 on latency_test (value);

During parallel batches with inserts and updates of a couple of thousands of records we noticed latency in replication to the read-replica, but also considerable latency on inserts and updates on the master, write node.

Looking at the CPU utilization it’s also noticeable that the instance is loaded a lot more on Aurora compared to RDS MySQL. Considering the RDS MySQL instance was of type db.m4.large (2 vCPUs, 8 GB RAM, 450 Mbps) and RDS Aurora instance was of type db.r4.large (2 vCPUs, 15.25 GB RAM, 400 Mbps), this would even make the difference in scaling bigger, something to take into account in case the architecture would be changed.