Aurora vs. RDS: engineering guide to choose the right AWS database for 2024
Once again, AWS is ranked among the top in the latest Gartner 2023 Magic Quadrant for Cloud Database Management Systems. The AWS OLTP relational database portfolio consists of 2 products:
Amazon RDS(Relational Database Service) was announced by AWS on October 22, 2009 and probably is the largest database fleet in the world.
Amazon Aurorawas announced on November 12, 2014, positioned as RDS premium providing unparalleled high performance and availability at global scale with full MySQL and PostgreSQL compatibility.
When an engineering team onboard AWS, one of the very first tasks is to choose Aurora or RDS as their main database (unless they decide to go NoSQL, then they need to pick between MongoDB and DynamoDB). Below we provide our engineering perspective to compare the following dimensions:
- Supported Databases
- High Availability
- Recommended Setup
RDS supports all mainstream relational databases including MySQL, PostgreSQL, MariaDB, SQL Server, Oracle, and Db2.
Aurora supports MySQL and PostgreSQL.
For RDS, you can choose all upstream versions. For Aurora, you are limited by a set of upstream versions mapped to the Aurora versions.
RDS mostly runs the vanilla database engines on the cloud. While Aurora is a cloud-native database service. Aurora is cloud-native because it leverages the cloud environment to separate compute and storage, uses Amazon S3 to persist data. This novel approach increase performance, high availability, and scalability.
Both Aurora and RDS bear the same limitation as a Cloud database:
- You can only have semi-super user.
- You are not allowed to access the database server file systems. For MySQL, this means
you can only use
LOAD DATA LOCALto import data from your local file system, while you can't use
LOAD DATAto import from the server file system.
Though Aurora is a proprietary technology, it mostly differs from the vanilla MySQL / PostgreSQL on the storage engine layer. On the other hand, the server layer, which determines most user-facing behaviors is almost identical. Thus the main compatibility gaps for Aurora is storage engine related. e.g. Aurora for MySQL only supports InnoDB, while RDS supports old engines such as MyISAM (however, you won't use MyISAM engine anyway if you start a new project).
Saying that, Aurora codebase diverges more from the vanilla MySQL/Postgres than RDS, thus you should expect more lags for the AWS team to bring in the latest upstream update. e.g. Aurora PostgreSQL added the popular pgvector extension 2 months later than RDS.
According to the official website, Aurora offers up to 5x the throughput of MySQL and 3x the throughput of PostgreSQL.
This benchmark suggesting Aurora can be 60 times faster than RDS.
Aurora provides better write performance because it reduces the write amplification by only sending the redo log to the remote storage service, which eliminates other writes during transaction commit path such as the infamous double-write buffer.
Aurora provides better read scalability because of the log-based architecture, it can support up to 15 read-replicas. RDS can only support 5, RDS doesn't support more because the classic streaming replication carries more performance penalty on the primary. Aurora also incurs much lower replication lags, especially under write-heavy load.
RDS uses EBS, the disk performance differs based on the storage types.
In general, Aurora outperforms RDS considerably. But you still need to benchmark for your own workload.
RDS doesn't have much elasticity, if you choose the gp2 SSD storage, it can be bursted and that's pretty much it.
Standard Aurora can provision read-replicas quickly, other than that, it doesn't provide elasticity out of the box.
Aurora Serverless and especially its Serverless v2 offers great elasticity to scale up/down computing resources. Great for workloads such as e-commerce.
RDS offers multi-AZ HA setup with a SLA of
up to 99.95%, while Aurora HA offers
up to 99.99%. Aurora can failover faster because of its log-based architecture. And for write-intensive load, RDS failover are more problematic because of the high replication lag.
Aurora also has global databases to enable low latency global reads and disaster recovery from outages across an AWS Region.
If you follow the AWS wizard to pick the production template (8c64g r6g.2xlarge + multi-AZ HA), you will find the price for Aurora is much cheaper than RDS. Too good to be true.
The caveat is Aurora also charges on I/O that is not included in the pricing estimate. This surprised quite a few customers when they receive a huge AWS bill. This unpredictable cost was the biggest concern for teams adopting Aurora initially. In 2023, Aurora fixed this by introducing Aurora I/O-Optimized to include the I/O cost in the storage.
Besides, only RDS offers free-tier and low db instance tiers starting from 2c1g t3.micro. Standard Aurora starts from 2c16g r5.large and burstable classes start from 2c4g t3.medium. Aurora Serverless can specify 0.5 ACU as the minimum. 1 ACU provides 2 GiB of memory and corresponding compute and networking.
Capability-wise, AWS Aurora beats RDS in almost every aspect. AWS also invests more resources in Aurora than in RDS since Aurora is a key differentiator from other cloud vendors. Though Aurora is mostly MySQL / PostgreSQL compatible, it creates a different vendor lock-in by providing unmatched ROI.
For bootstrapped or small business, Aurora is still pricy and RDS is a cost-effective solution:
|RDS without HA
|RDS with HA
For growth stage business, Aurora is more suitable, and Aurora Serverless offers the extra flexibility to optimize the cost.
|Always-on Test Instance
|Standard Aurora without HA
|On-demand Test Instance
|Aurora Serverless without HA
|Standard Aurora with HA
|Prod Instance with fluctuate traffic
|Aurora Serverless with HA
Normally, you should start with RDS and migrate to Aurora when the business takes off. AWS provides detailed guide on how to migrate from RDS to Aurora with near zero downtime.
After you decide the database product, there remains task to figure out the database development workflow:
- How developers propagate the change from dev to production?
- How to get the SQL change peer-reviewed by the DB person in an efficient manner? Or even better with automated SQL checks?
- How to enforce data access policy for PII compliance?
If you are thinking about these problems, please check out Bytebase. It's an all-in-one tool to centralize all human-to-db operations for heterogeneous databases.
- Postgres vs. MySQL: a Complete Comparison
- Amazon Aurora ascendant: How we designed a cloud-native relational database
- Amazon database master user account privileges
- Amazon Aurora features
- Amazon Aurora pricing
- Using Aurora Serverless v2
- High availability for Amazon Aurora
- Amazon RDS features
- Amazon RDS pricing
- Amazon RDS DB instance storage