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.
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.
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.
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.
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.
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.
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.
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.
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!
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 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.
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.
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.
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.
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.
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
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.
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.
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.
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.
The cost differences between Aurora and RDS vary depending on the chosen database engine, storage, instance type, and usage.
Some examples:
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.
Read more of our blog series:
The Benefits of Amazon RDS for MySQL
Embrace the Cloud with Microsoft Azure
Benefit from Ongoing Innovation with Google Cloud
Need help with your cloud migration? Contact us today.
Resources
RELATED POSTS
