Aurora vs RDS: How to Choose the Right AWS Database Solution

This post was originally published in July 2018 and was updated in July 2023.

Now that Database-as-a-service (DBaaS) is in high demand, there are multiple questions regarding AWS services that cannot always be answered easily: When should I use Aurora and when should I use RDS MySQL? What are the differences between Aurora and RDS? How do I choose which one to use?

In this blog, we will answer all of these important questions and provide a general overview comparing the two database services, Aurora vs RDS.

Understanding DBaaS

DBaaS cloud services allow users to use databases without configuring physical hardware and infrastructure or installing software. But when trying to find out which solution best fits an organization, multiple factors should be taken into consideration. These may be performance, high availability, operational cost, management, capacity planning, scalability, security, monitoring, etc.

There are also cases where although the workload and operational needs seem to best fit to one solution, there are other limiting factors that may be blockers (or at least need special handling).

What we should really compare is the MySQL and Aurora database engines provided by Amazon RDS.

Download our eBook, “Enterprise Guide to Cloud Databases” to help you make more informed decisions and avoid costly mistakes as you develop and execute your cloud strategy.
Download Now

What is Amazon Aurora?

Amazon Aurora is a proprietary, cloud-native, fully managed relational database service developed by Amazon Web Services (AWS). With its support for MySQL and PostgreSQL, and its automated replication and backup capabilities, it’s designed to deliver high performance, scalability, and availability to meet the needs of mission-critical applications.

Aurora Features

High Performance and Scalability

Amazon Aurora has gained widespread recognition for its exceptional performance and scalability, making it an ideal solution for handling demanding workloads. It efficiently manages read and write operations, optimizes data access, and minimizes contention, resulting in high throughput and low latency to ensure that applications perform at their best.

Aurora offers several scalability options, including allowing for the addition of up to 15 read replicas for a single database cluster, the support of auto-scaling of read replicas, the creation of cross-region read replicas for disaster recovery and improved read performance in varying geographic locations, and storage auto-scaling that can accommodate data growth without the need for constant monitoring.

Compatibility with MySQL and PostgreSQL

Aurora offers seamless compatibility with MySQL and PostgreSQL, enabling developers and DBAs to utilize their existing database skills and use the latest features and enhancements.

For those with applications already built on MySQL or PostgreSQL, migrating to Aurora is a straightforward process requiring minimal code changes, as it supports the same protocols, tools, and drivers.

Automated Backups and Point-in-Time Recovery

Aurora provides automated backup and point-in-time recovery, simplifying backup management and data protection. Continuous incremental backups are taken automatically and stored in Amazon S3, and data retention periods can be specified to meet compliance requirements.

The point-in-time recovery (PITR) feature enables the restoration of a database to a specific time within the set retention period, making it easier to roll the application back to a specific state or recover from accidental/purposeful data corruption.

These automated features reduce the burden on DBAs and organizations for their data protection efforts by simplifying database backups and recovery.

Multi-Availability Zone (AZ) Deployment

Aurora’s Multi-Availability Zone (AZ) deployment offers remarkably high availability and fault tolerance by automatically replicating data across multiple availability zones using its distributed storage architecture to eliminate single points of failure. The continuous synchronization between the primary and replica ensures real-time redundancy, and if a disruption occurs in the primary, Aurora seamlessly switches to the replica with automatic failover, providing for uninterrupted availability.

What is Amazon RDS?

Amazon Relational Database Service (Amazon RDS) is a hosted database service that provides multiple database products to choose from, including Aurora, PostgreSQL, MySQL, MariaDB, Oracle, and Microsoft SQL Server.

RDS Features

Managed Database Service

Amazon RDS is a fully managed database service provided by AWS, offering a simpler way to operate and maintain relational databases in the cloud. AWS handles essential administrative tasks, including database setup, configuration, backups, monitoring, and scaling, making it easier for businesses to manage complex database infrastructures.

By offloading these administrative tasks to AWS, DBAs, and developers do not need to spend time on manual tasks like software installation and hardware provisioning, instead freeing up time for them to work on more business-centric activities while reducing costs.

Considering a Fully Managed DBaaS Offering For Your Business? Percona can Help

Multiple Database Engine Options

Amazon RDS supports various database engine options, including MySQL, PostgreSQL, Oracle, and SQL Server, offering organizations the flexibility of choosing the right engine for any specific requirements. By offering these options, Amazon RDS empowers developers to cater their database infrastructure to the unique needs of their applications, performance expectations, and compliance requirements while ensuring compatibility and efficiency across the business.

Providing a straightforward way of migrating existing databases, RDS supports several migration methods, including data imports from existing backups and leveraging AWS Database Migration Services (DMS) for real-time migration. This flexibility helps businesses seamlessly transition their databases to the AWS cloud without significant disruptions.

Automated Backups and Point-in-Time Recovery

Amazon RDS offers an automated backup feature that ensures data integrity and provides reliable data protection. It automatically takes regular backups, capturing incremental changes since the last backup without affecting performance. Users can set a retention period for these backups, allowing historical data recovery in case of accidental data loss or corruption, and point-in-time recovery (PITR) allows users to restore the database to any specific moment within the set retention period. This capability is valuable for reverting to a previous state, whether to recover from data corruption or any other incident.

The RDS automated backup and PITR capabilities protect against data loss and system failures, ensuring high availability and performance while simplifying backup management for developers and DBAs.

Scalability and Elasticity

Amazon RDS offers several scalability options so organizations can adjust resources to meet changing application and workload needs. Vertical scaling allows for increases in the compute and memory capacity via upgrades to larger instance types, ideal for handling traffic demands or processing needs, while horizontal scaling involves adding read replicas to distribute workloads across multiple instances, enhancing read scalability for read-heavy applications.

RDS also simplifies the process of automatic scaling based on workload demand, adding or subtracting replicas to efficiently distribute read requests and reduce costs during low demand. It also supports auto-scaling of compute and storage resources, dynamically adjusting capacity based on chosen utilization thresholds to optimize performance and costs.

This flexibility to adjust resources based on changing needs provides organizations with the ability to dynamically respond to variations in demand without manual intervention — all while delivering optimal performance and reducing expenses.

Exploring the Similarities Between Aurora vs. RDS

When comparing Amazon Aurora and Amazon RDS, it becomes evident that both solutions offer time-saving benefits in systems administration. With both options, you receive a pre-configured environment ready to deploy your applications. Particularly in the absence of dedicated database administrators (DBAs), Amazon RDS provides great flexibility for various operations, including upgrades and backups.

Both Amazon Aurora and Amazon RDS share the advantage of seamless updates and patches applied by Amazon without any downtime. You have the ability to define maintenance windows, allowing automated patching to occur within those specified timeframes. Additionally, data is continuously backed up to Amazon S3 in real-time, ensuring data protection without any noticeable impact on performance. This eliminates the need for complex or scripted backup procedures and designated backup windows.

While these shared features offer significant convenience, it is important to consider potential factors such as vendor lock-in and the challenges that may arise from enforced updates and client-side optimizations.

Aurora vs. RDS: Comparing the key differences

In this section, we will explore the distinctive features and characteristics of Amazon Aurora and Amazon RDS, shedding light on their performance, scalability, pricing models, and more.

Amazon Aurora is a relational, proprietary, closed-source database engine with all that that implies.

RDS MySQL is 5.5, 5.6, and 5.7 compatible and offers the option to select among minor releases. While RDS MySQL supports multiple storage engines with varying capabilities, not all of them are optimized for crash recovery and data durability. Until recently, it was a limitation that Aurora was only compatible with MySQL 5.6, but it’s now compatible with both 5.6 and 5.7 too.

So, in most cases, no significant application changes are required for either product. Remember that certain MySQL features like the MyISAM storage engine are not available with Amazon Aurora. Migration to RDS can be performed using Percona XtraBackup.

For RDS products, shell access to the underlying operating system is disabled, and access to MySQL user accounts with the “SUPER” privilege isn’t allowed. To configure MySQL variables or manage users, Amazon RDS provides specific parameter groups, APIs, and other special system procedures which are used. If you need to enable Amazon RDS remote access, this article will help you do so.

Performance considerations

For example, due to the need to disable the InnoDB change buffer for Aurora (this is one of the keys for the distributed storage engine) and that updates to secondary indexes must be write-through, there is a big performance penalty in workloads where heavy writes that update secondary indexes are performed. This is because of the way MySQL relies on the change buffer to defer and merge secondary index updates. If your application performs a high rate of updates against tables with secondary indexes, Aurora performance may be poor. As you may already have noticed, AWS claims that the query_cache feature can be used and that it does not suffer from scalability issues. Personally speaking, I’ve not seen any issues related to query_cache, and this feature can significantly improve the overall performance.

In any case, you should always keep in mind that performance depends on schema design. Before making the decision to migrate, performance should be evaluated against an application-specific workload. Doing extensive benchmarks will be the subject of a future blog post.

Let Percona Actively Manage Your Databases To Achieve Peak Performance. Learn more here!

Capacity Planning

Talking about underlying storage, another important thing to consider is that with Aurora, there is no need for capacity planning. Aurora storage will automatically grow, from the minimum of 10 GB up to 64 TiB, in 10 GB increments, without impacting database performance. The table size limit is only constrained by the size of the Aurora cluster volume, which has a maximum of 64 tebibytes (TiB). As a result, the maximum table size for a table in an Aurora database is 64 TiB. For RDS MySQL, the maximum provisioned storage limit constrains the size of a table to a maximum size of 16 TB when using InnoDB file-per-table tablespaces.

For RDS MySQL, there has recently been added a new functionality, called Storage autoscaling. When you create your instances, you can enable that option, and it’s more or less similar to what Aurora offers. Further details can be found here.

As of Aug 2018, Aurora provides another option that does not require provisioned capacity. It’s Aurora Serverless.

“Amazon Aurora Serverless is an on-demand, auto-scaling configuration for Amazon Aurora (MySQL-compatible and PostgreSQL-compatible editions), where the database will automatically start up, shut down, and scale capacity up or down based on your application’s needs. It enables you to run your database in the cloud without managing any database instances. It’s a simple, cost-effective option for infrequent, intermittent, or unpredictable workloads.
Manually managing database capacity can take up valuable time and can lead to inefficient use of database resources. With Aurora Serverless, you simply create a database endpoint, optionally specify the desired database capacity range, and connect your applications. You pay on a per-second basis for the database capacity you use when the database is active, and migrate between standard and serverless configurations with a few clicks in the Amazon RDS Management Console.”

In order to use Aurora Serverless, you have to select so while creating your instances, and you also need to set a couple of capacity settings that have to do with scaling.

Although this feature initially sounds fantastic, there are some limitations. Some of them are really major.

Due to the limitations listed above, in my opinion, Aurora Serverless is better mainly for dev environments or systems that are needed for just a few hours/day or a short period of time. At the end of the day, you can shut it down, thus reducing your overall costs. From my experience, boot time may be a bit higher.

Replication

Replication is a really powerful feature of MySQL (like) products. With Aurora, you can provision up to fifteen replicas compared to just five in RDS MySQL. All Aurora replicas share the same underlying volume with the primary instance. This means that replication can be performed in milliseconds as updates made by the primary instance are instantly available to all Aurora replicas. Failover is automatic with no data loss on Amazon Aurora, whereas the replicas failover priority can be set.

Architecture

An explanatory description of Amazon Aurora’s architecture can be found in Vadim’s post written a few years ago.

The architecture used and the way that replication works on both products shows a really significant difference between them. Aurora is a High Availability (HA) solution where you only need to attach a reader, and this automatically becomes Multi-AZ available. Aurora replicates data to six storage nodes in Multi-AZs to withstand the loss of an entire AZ (Availability Zone) or two storage nodes without any availability impact on the client’s applications.

On the other hand, RDS MySQL allows only up to five replicas, and the replication process is slower than Aurora. Failover is a manual process and may result in last-minute data loss. RDS for MySQL is not an HA solution, so you must mark the master as Multi-AZ and attach the endpoints.

Monitoring

Both products can be monitored with a variety of monitoring tools. You can enable automated monitoring, and you can define the log types to publish to Amazon CloudWatch. Percona Monitoring and Management (PMM) can also be used to gather metrics.

Be aware that for Aurora, there is a limitation for the T2 instances such that Performance Schema can cause the host to run out of memory if enabled.

Costs

Aurora instances will cost you ~20% more than RDS MySQL. If you create Aurora read replicas, then the cost of your Aurora cluster will double. Aurora is only available on certain RDS instance sizes. Instances pricing details can be found here and here.

Storage pricing may be a bit tricky. Keep in mind that pricing for Aurora differs from that for RDS MySQL. For RDS MySQL, you have to select the type and size for the EBS volume, and you have to be sure that provisioned EBS IOPs can be supported by your instance type, as EBS IOPs are restricted by the instance type capabilities. Unless you watch for this, you may end up having EBS IOPs that your instance cannot really use.

For Aurora, IOPs are only limited by instance type. This means that if you want to increase IOPs performance on Aurora, you should proceed with an instance type upgrade. In any case, Amazon will charge you based on the dataset size and the requests per second.

Although for Aurora you pay only for the data you really use in 10GB increments, if you want high performance, you have to select the correct instance. For Aurora, regardless of the instance type, you get billed $0.10 per GB-month and $0.20 per 1 million requests. If you are looking for high performance, the cost may be even more for Aurora as compared to RDS MySQL. For RDS MySQL, storage costs are based on the EBS type and size.

Support for RDS Services

Percona provides round-the-clock, fully managed support for RDS services at a fraction of the cost of a full-time, dedicated DBA.

For example, one Percona client, Madwire, engaged Percona to provide recommendations on the best way to achieve faster response times from their SQL-based reports. As a result of using Percona’s managed database services, they didn’t need to hire their own DBA and achieved significant cost savings. View the full results of the case study here. When a more fully customized solution is required, most of our customers usually prefer using AWS EC2 instances supported by our managed services offering.

In Summary: Should I Use Aurora or RDS?

If you are looking for a native HA solution, then you should use Aurora.
For a read-intensive workload within an HA environment, Aurora is a perfect match. Combined with ProxySQL for RDS, you can get high flexibility.
Aurora performance is great but is not as much as expected for write-intensive workloads when secondary indexes exist. In any case, you should benchmark both RDS MySQL and Aurora before taking the decision to migrate. Performance depends much on workload and schema design.
By choosing Amazon Aurora, you are fully dependent on Amazon for bug fixes or upgrades.
If you need to use MySQL plugins, you should use RDS MySQL.
Aurora only supports InnoDB. If you need other engines, i.e., MyISAM, RDS MySQL is the only option.
With RDS MySQL, you can use specific MySQL releases.
Aurora is not included in the AWS free tier and costs a bit more than RDS MySQL. If you only need a managed solution to deploy services in a less expensive way and out-of-the-box availability is not your main concern, RDS MySQL is what you need.
If, for any reason, Performance Schema must be ON, you should not enable this on Amazon Aurora MySQL T2 instances. With the Performance Schema enabled, the T2 instance may run out of memory.
For both products, you should carefully examine the known issues and limitations listed here https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.KnownIssuesAndLimitations.html and here https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.AuroraMySQL.html.

Looking for a Database Migration Solution? Percona can Help

Whether Amazon Aurora or RDS MySQL is best suited for your organization’s unique needs, we can help with the migration of your database with Percona XtraBackup. Percona XtraBackup is a free, online, open source, and complete database backup solution. With XtraBackup, you can take an online physical backup of your database and restore it into a new Aurora or RDS MySQL instance. Read our blog to learn how to migrate your existing database to Amazon RDS. It covers everything you need to know for a successful migration.

Get Started with Percona XtraBackup

FAQ

What is the difference between Amazon Aurora vs Amazon RDS?

Amazon Aurora is a proprietary, fully-managed relational database engine that is MySQL and PostgreSQL-compatible. Amazon RDS is a hosted database service that supports a variety of relational database engines, including MySQL, PostgreSQL, MariaDB, Microsoft SQL Server, and Oracle.

How does the performance of Amazon Aurora compare to Amazon RDS?

Amazon Aurora generally outperforms Amazon RDS, especially for read-intensive and mission-critical workloads in a High Availability environment. And while Amazon RDS is a fully capable and reliable managed service, its performance relies on the database engine being utilized.

How does high availability work in Amazon Aurora vs Amazon RDS?

Amazon Aurora and Amazon RDS both offer high availability features. Aurora’s rapid failover mechanisms and distributed storage make it better suited for demanding and critical applications, while RDS provides Multi-AZ deployments for failover, ensuring redundancy in a single region. Check out The Ultimate Guide to Database High Availability for a deeper dive.

Can I use read replicas in both Amazon Aurora and Amazon RDS?

Yes, you can use read replicas in both Amazon Aurora and Amazon RDS. An Aurora cluster can contain up to 15 replicas distributed across different Availability Zones. In RDS, read replicas are available for MySQL, PostgreSQL, MariaDB, Oracle, and SQL Server database engines, allowing you to create one or more replicas of a given source DB Instance.

What are the cost differences between Aurora vs RDS?

The cost differences between Aurora and RDS vary depending on the chosen database engine, storage, instance type, and usage.

Some examples:

While RDS supports such database engines as MySQL, PostgreSQL, and MariaDB, and the pricing may differ based on which is used, Aurora is a database engine made by AWS so its pricing is typically different from RDS instances.
Data transfer costs between different AWS regions and services can vary, so it’s important to understand these costs if your application requires communication between Aurora or RDS instances and other AWS resources.
The cost of read replicas in RDS depends on the number of replicas needed and their size, while Aurora provides up to 15 read replicas at no additional cost beyond the storage and data transfer costs.
With some database engines, such as Oracle, there may be licensing costs associated with using RDS. Aurora, on the other hand, is a proprietary engine with licensing fees built into its price.

As you consider Aurora vs. RDS, it’s vital to understand your specific needs and usage patterns to determine the most cost-effective option that will work for you.