Skip to Content

A first look at Amazon Aurora with MySQL/PostgreSQL compatibility – Benefits and Drawbacks – Part I

Posted on October 31, 2022 by

Categories: AWS


A subsidiary of the e-commerce behemoth,, Amazon Web Services (AWS) was established in 2006 to offer Infrastructure as a Service (IaaS) cloud capabilities to third parties for a fee. Fast provisioning of virtual machines in any of AWS’s global data centres on a pay-as-you-go basis was made possible by this (with possibilities for paying in advance). IaaS offerings from AWS included the Elastic Compute Cloud (EC2) and the Simple Storage Service (S3). Two years after EC2’s first release, the block-level storage option Elastic Block Store (EBS) was introduced. This made it possible to provide “permanent” storage for EC2 instances, which had previously been impossible. Since its humble beginnings in 2006, AWS has expanded exponentially to become the dominant player in the Cloud Infrastructure services industry.

When AWS was launched, IT professionals and sales engineers used it to showcase their products to prospective clients. Until recently, even massive software distributors like Oracle were using AWS for product demonstrations. Instead of the sales engineers configuring servers, installing software on each server, and then using it for the test, demo, or workshop, they utilized AWS. It was an excellent, speedy method of booting up a few virtual computers that had already been set up and used for the presentation or workshop. A business credit card was all that was required.

Due to its low cost, AWS was initially adopted by developers for use in their own development operations; as time went on, businesses began moving their test or development servers to AWS. Right now, complete operational data centres are being shifted to AWS. Companies of all sizes are beginning to see the benefits of cloud computing for their production servers. Financial institutions are also making a move to the AWS cloud, according to the company’s seminars; one such institution is the DBS bank in Singapore, which has recently made public announcements about its plans to migrate 50 per cent of its compute workload to the AWS cloud within the next two years. Some banks use AWS for disaster recovery, while others use it for development and testing, customer and marketing analytics, risk management, digital and mobile banking, blockchain, and Internet of Things (IoT) via Alexa and Echo (such as asking for price quotations).

All of EC2’s virtual machines run on the Xen hypervisor. In contrast to other cloud providers, AWS does not provide a “bare metal” computing solution, which would let you utilize your own server licences and run without the performance hit of virtualization. Oracle’s compute cloud offers bare metal computing services.

To recap our trip so far, in the past, when individuals used AWS for database demos and tests, they installed their own database software on the offered virtual servers and constructed their own databases. However, in 2009, AWS launched the Amazon Relational Database Service (Amazon RDS). Because of this, it was simple to utilize AWS to set up a new database server with the necessary database software already installed, a feature known as “Database as a Service” (DBaaS) that differs from Infrastructure as a Service (IaaS). A new database was created in response to the service request.

As part of the RDS service, AWS takes care of database administration tasks, including backing up and updating the database’s software. Amazon RDS first supported MySQL, then Oracle, Microsoft SQL Server, PostgreSQL, and finally MariaDB, a derivative of MySQL.

After five years of research into the possibilities of database optimization for the cloud, AWS released Amazon Aurora in 2014, having discovered the promise of a “cloud-optimized” database. This database shared features with MySQL 5.6 and was built specifically for use in cloud environments.

It was intended to make DBaaS more cost-effective. Amazon S3, a multi-tenant and database-optimized storage solution that can scale out on demand and interface with other AWS services, was the primary method chosen since it allowed the logging and storage layer to be moved off-premises. Figure 1 shows this clearly

Aurora with Amazon’s Integrated Services

As data was stored on the cloud and independently, it was easy to scale. Amazon Aurora uses SSD storage arrays that can automatically extend up to 64TB in size, with increments of 10GB as needed. When using an Aurora database, data is automatically duplicated across three AWS data centres (AZs). For redundancy, data is replicated twice in every Availability Zone. The storage is highly reliable and up to 99.99%, thanks to the design. In the case of instance or storage failure, automated recovery is initiated.

The Aurora database only needs four out of every six writes to be finished before continuing. This kind of writing, called quorum writing, is very good at putting out fires. The storage design also allows for fast, parallelized, continuous backups to the Amazon Simple Storage Service (S3) with zero influence on the database instance server’s performance. Database administrators (DBAs) may rest easy knowing that regular backups of their data are being performed automatically. If necessary, the DBA may roll back the database to an earlier time, down to the second.

Another perk is that you may make as many as 15 copies of your Amazon Read from the original database (manually, not automatically). Application reads can be performed on these read replicas and can also be utilized as a failover target. Since the storage for both the primary database and the read replicas is shared, the replication to the replicas is fine-grained and practically synchronous, with a delay of around 10 to 20 ms.

Please be aware that this is a manual change, and the programme must be informed where to read from and write to. The application’s read queries should only be processed by the web/application servers configured to use the read replicas. The application’s write queries should only be processed by the web/application servers communicating with the primary instance.

Therefore, unlike a real active-active read-write cluster, the application’s usage of reading replicas is not apparent. Writing to the database implies there is no “auto-scaling” in the traditional sense, which may be viewed as a disadvantage. Moving your primary database to a more capable database server instance is one possibility. Still, it requires vertical scalability, and downtime and, for some of us, brings back memories of the days when hardware makers insisted their customers perform such migrations. Many believed this problem was resolved by horizontal scalability and active-active database clustering. However, active-active database clustering is not available in the case of Amazon Aurora.

AWS developed a database migration service and a schema conversion tool to make the switch to the Aurora MySQL-compatible database easier. While they offer some useful features, they also have a few downsides. The second instalment of this series will go deeper into that topic. The second half of this article may be found here.

(Disclaimer: The author’s opinions are their own and do not represent those of Amazon Web Services (AWS) or Oracle Corporation. As of February 2017, the author has no ties to AWS or Oracle and is not employed by either company. The author used to work for Oracle, but now she’s a cloud consultant who doesn’t take sides.