Aurora RDS vs MySQL RDS

Aurora RDS vs MySQL RDS

Amazon Aurora is a relational database engine that delivers the speed and reliability of commercial databases with the benefits of open source databases. Amazon RDS, on the other hand, is very easy to set up, operate and scale MySQL deployments in the cloud. If you are planning to use one of the two, I have listed some comparisons in the table below:

Features Amazon RDS for Aurora Amazon RDS for MySQL
Performance According to Amazon, Aurora offers five times the performance of a standard deployment of a MySQL instance. The performance of RDS is good.
Compatibility The Amazon Aurora database engine is designed to be compatible with MySQL 5.6 Supports MySQL versions 5.1, 5.5, and 5.6.
Storage Engine Supports only InnoDB. Tables from other storage engines are automatically converted to InnoDB. Supports InnoDB, MyISAM and many others
Availability according to region Amazon Aurora is currently available in the US West (Oregon), US East (N. Virginia), and EU (Ireland) AWS regions. Available in all AWS regions
Simulation for crash testing Simulation of node, disk, or read replica failure for testing/HA using queries No support for simulating crashes for testing purpose using queries
Workload Supports highly concurrent workloads. Supports normal workloads.
Storage AutoScaling Amazon Aurora storage is fault-tolerant, self-healing, transparently handling the loss of up to two copies of data without affecting database write availability and up to three copies without affecting read availability. Amazon Aurora automatically maintains 6 copies of your data across 3 Availability Zones and will automatically attempt to recover your database in a healthy AZ with no data loss. The minimum storage is 10GB. Based on your database usage, your Amazon Aurora storage will automatically grow, up to 64 TB, in 10GB increments with no impact to database performance. There is no automatic growth of storage.
Encryption Amazon Aurora uses SSL (AES-256) to secure data in transit. Encryption for data at rest will be available in a future release. Amazon RDS encryption uses AWS Key Management Service (KMS) to let you create and manage the keys used to encrypt your data.
Replica Amazon Aurora supports two kinds of replicas.
1. Amazon Aurora Replicas share the same underlying volume as the primary instance. There can be maximum of 15 Aurora replicas.
2. MySQL Read Replicas based on MySQL’s binlog-based replication engine. In MySQL Read Replicas, data from your primary instance is replayed on your replica as transactions.
It support only read replica. There can be maximum of 5 read replica
Cost The minimum instance of Aurora start from db.r3.large. Hence, it is costlier than RDS for MySQL. With Amazon Aurora you pay only for the storage that you use. RDS MySQL is cost effective, especially as it is currently available on lower-spec VMs. With MySQL RDS, you pay for the storage that is attached to your VMs whether you are using it or not.
Backup and its impact on DB performance Amazon Aurora backups are automatic, incremental and continuous and have no impact on database performance. Amazon RDS automatically performs a full daily snapshot of your data (during your preferred backup window) and captures transaction logs (as updates to your DB Instance are made). During the backup window, storage I/O may be suspended while your data is being backed up and you may experience elevated latency. This I/O suspension typically lasts for the duration of the snapshot.
Failure Detection and Correction/Resilience Aurora can detect a database failure and recover in less than a minute, without the need to rebuild (or “warm”) the database caches that are needed to speed response times. In the case of a permanent failure, Aurora can automatically failover to a replica without losing any data. Failovers, as defined by the interval between the detection of the failure on the primary and the resumption of transactions on the standby, typically complete within one to two minutes.
Crash Recovery Crash recovery is very fast as compared to RDS for MySQL. Amazon Aurora does not need to replay the redo log from the last database checkpoint (typically 5 minutes) and confirm that all changes have been applied, before making the database available for operations. Crash recovery is slow as compared to Aurora. It has to replay the redo log since last check point, which is single threaded in MySQL.
Replication/Multi AZ Failover Unplanned failover takes place within minutes. Failover to a replica, if you maintain multiple instances, is almost immediate and automatic, since all replicas use the same logging and storage layers. Unplanned failover typically completes within one or two minutes and is not automatic in case of read replica.
Incremental backup Aurora supports incremental backups. No support for incremental backups
Cache/Buffer Aurora also isolates the database buffer cache from the database process, allowing the cache to survive a database restart. The buffer cache and database share the same process so cache will not be flushed to disk if you restart the instance.
Replication Lag There is negligible lag between updating the primary instance and reading the data back from a read replica since they are sharing same storage. Almost 400x TIMES lowered read replica lag over MySQL. Replication lag will be high as compared to Aurora replica.
Read Replicas with a different storage engine than the master instance MySQL (non-RDS) read replicas that replicate with an Aurora DB cluster can only use InnoDB. Read replicas can use both MyISAM and InnoDB.
Database engine parameters Some parameters apply to the entire Aurora DB cluster and are managed by DB cluster parameter groups. Other parameters apply to each individual DB instance in a DB cluster and are managed by DB parameter groups. Parameters apply to each individual DB instance or Read Replica and are managed by DB parameter groups.


In my opinion, Aurora RDS is better than MySQL in most cases and is highly recommended. However, there are some scenarios when you cannot use Aurora RDS:

  • When your application is a heavy read only, the application will be more benefitted by MyISAM storage engine instead of Aurora RDS.
  • If the resource (CPU, memory) requirement of the DB is less, you cannot opt for Aurora RDS.
  • If there is a specific requirement for MySQL version earlier than 5.6, you cannot use Aurora.


Topics: Aurora MySQL MySQL RDS Aurora RDS RDS cloud computing Technology

Converting from MySQL to Elasticsearch

While working on a project called Lantanacloud at e-Zest Solutions Ltd. India, the project was initially implemented using MySQL for database storage. Later on we decided to use ElasticSearch for two primary reasons:

Topics: MySQL NoSQL database Elasticsearch cloud computing Technology RDBMS

Pentaho configuration for MySQL

Steps to change Pentaho preconfigured hypersonic database to MySQL

Topics: Pentaho Liferay Integration business intelligence MySQL pentaho Technology

Basic Apache Solr search analysis using PHP & log4j

If you are using Apache Solr as a search engine for your application then it is necessary to analyze Solr logs to improve your user experience and application performance.

Topics: Apache Solr PHP MySQL Solr Log Parse Solr logs log4J Solr search analysis Technology LAMP

Configuring Unicode support in Spring + Hibernate + MySQL + JSP Application

In this blog I will show you how I have configured Unicode in Spring Hibernate and MySQL project where we are using JSP for the client side.

Topics: hibernate Spring UTF-8 MySQL JSP Technology Unicode

e-Zest Solutions is digital experience engineering company with facilities in the United States (Detroit & San Jose), Germany (Hannover), United Kingdom (London UK) and India (Pune) with global clientele. Our services include custom software development, offshore software development, UX consulting, BigData, Managed cloud Services (Azure & AWS), SharePoint consulting/Migration, Enterprise Java application development, Automated software testing services.