Skeddly Blog

Comparing Managed MySQL Services on AWS, Azure, and GCP

MySQL is a popular open-sourced relational database server. It comes in many flavours, including Enterprise and Community editions.

Amazon Web Services, Microsoft Azure, and Google Cloud Platform all provide their own managed MySQL services. The available versions and features vary from provider to provider. As an added complexity, AWS provides three different MySQL services, each one of them different. Let’s take a closer look.

First off, I want to prefix this comparison by saying that in the case of all three providers, you can host MySQL on your own instances/VMs. This comparison only includes managed services, and does not include such host-your-own implementations.

I also want to add that I am not comparing the performance of each service.

Amazon Web Services

AWS offers three different options for MySQL:

• Amazon RDS for MySQL
• Amazon Aurora
• Amazon Aurora Serverless

There are enough differences between the three that I will be separating them.

Amazon RDS for MySQL

Amazon Web Service’s first offering is Amazon RDS for MySQL.

Some key points:

• Amazon RDS for MySQL supports MySQL versions 5.5 to 8.0.
• For high-availability, you can choose from stand-alone instances or replicated Multi-AZ instances.
• RDS has it’s own native DB snapshot method which you can use on your instances. You can create DB snapshots, then restore fresh instances from your DB snapshots. Backups are region-local, but can be copied to other regions.

Amazon Aurora

Later, Amazon Web Service’s came out with Amazon Aurora. Amazon Aurora has both MySQL and PostgreSQL compatibility.

From an infrastructure perspective, this was a major departure from traditional databases. Traditional databases were built to mainly execute on a single server. Replicas are used to distribute readers and writers. Aurora introduced a common storage system, accessed by multiple readers and writers.

Some key points:

• Amazon Aurora supports MySQL versions 5.6 and 5.7. However, Aurora version numbers deviate and mask the actual MySQL minor versions used.
• All Amazon Aurora clusters run as highly-available.
• Storage is not pre-provisioned.
• Amazon Aurora has it’s own native cluster snapshot method which you can use on your clusters. You can create cluster snapshots, then restore fresh clusters from your cluster snapshots. Snapshots are region-local, but can be copied to other regions.
• Amazon Aurora supports “multi-master” mode in a single region. So you can have up to five writers in a single Aurora cluster.
• Amazon Aurora is not actually “MySQL Server”. Instead, it’s just “MySQL compatible”. So there is the risk of some behaviour differences between Aurora and true MySQL server.

Amazon Aurora Serverless

After Aurora, AWS came out with Amazon Aurora Serverless. Amazon Aurora Serverless also has both MySQL and PostgreSQL compatibility.

From an infrastructure perspective, all you see is a cluster. Readers and writers are scaled up and down on demand based on pre-configured specifications (like Auto Scaling for EC2).

Some key points:

• Amazon Aurora Serverless only supports MySQL version 5.6. Again, Aurora Serverless version numbers deviate and mask the actual MySQL minor versions used.
• All Amazon Aurora Serverless clusters run as highly-available.
• Storage is not pre-provisioned.
• Amazon Aurora Serverless has it’s own native cluster snapshot method which you can use on your clusters. You can create cluster snapshots, then restore fresh clusters from your cluster snapshots. Snapshots are region-local, but can be copied to other regions.

Microsoft Azure

Microsoft Azure’s MySQL service is called Azure Database for MySQL.

• Azure currently supports MySQL versions 5.6 to 8.0. Minor versions cannot be selected.
• All MySQL servers on Azure are configured for high-availability, a stand-alone option does not exist.
• Azure MySQL servers can be backed up using a native method. Backups are geo-redundant.

Google Cloud Platform

Google Cloud Platform’s MyQL service is called Cloud SQL for MySQL.

• GCP currently supports MySQL versions 5.6 and 5.7. Minor versions cannot be selected.
• For high-availability, you can choose from stand-alone instances or replicated instances.
• Native backups can be created from your MySQL instances. By default, backups are not geo-redundant, but with some command-line commands, they can be.

Comparisons

Price

Comparing the hourly cost in “US East” regions, GCP comes away with the least expensive way to run a MySQL server.

If you’re doing development, make sure you stop your database servers when they’re not in use. Amazon RDS and Aurora supports this. Amazon Aurora Serverless can reduce itself to 0 Aurora Capacity Units if not in use.

Version

As of this writing, the current version of MySQL server is 8.0.19.

Amazon RDS for MySQL provides the most choices of MySQL versions. It also is the easest to choose specific minor versions.

¹ Aurora server versions are different than the MySQL version. This can make it unclear which minor version of MySQL is being used.
² Minor versions are not selectable.

High-Availability

For databases, high-availability means redundancy, data replication, and failover availability.

When getting started, a stand-alone database will provide the least expensive option. That’s great for development, but it’s not enough for a higly-available, production environment.

The high-availability method used by Amazon RDS for MySQL, Azure, and GCP is to have two MySQL servers synchronized: a primary server, and a hot standby. Data is synchronously replicated from the primary to the standby. When a failure happens on the primary, their roles swap, and the standby becomes the primary.

Amazon Aurora and Aurora Serverless do it differently. Instead, the data storage is separated from the operating server. Data is always replicated (4 of 6 quarum), even in a single-instance scenario. Readers and writers all share the same data storage (within the same region). If a server fails, a new server can be created to replace it, and it will simply access the same data layer.

All services allow you to create read-replica servers to help distribute the reading load off the primary servers.

Amazon Aurora can operate in a multi-master scenario. This means that you can have multiple writers writing to the same database.

¹GCP documentation does not indicate that multi-region read-replicas are possible. However, the Google Cloud Console UI seems to indicate that either it’s possible in a scenario that I have not found yet, or it may be possible in the future.

Storage

As previously mentioned, the traditional way to provide high-availability is to duplicate the data between a primary server and a hot standby server. This requires twice the storage along with synchronous replication. Each read-replica also required it’s own copy of the data, which adds to the storage costs.

Amazon Aurora instead keeps the data separate from the operating servers. So there is only a single data plane to pay for. It’s still replicated, but you don’t see that.

Also, traditionally, storage was pre-provisioned. Which meant you needed to plan ahead about the potential amount of data your database will need to hold. Today, all offerings support automatic storage growth. So if you run out of storage, it can expand the allocated storage. This means you can start small, and grow as you need to.

All services offer to store your data encrypted.

Backups

All services support a native backup method. This lets you create backups and restore new servers from the backups.

Some backups are geo-redundant automatically. This means that your backup is replicated in two or more regions. Amazon allows you to copy your backups between regions as needed.

Amazon Aurora and Google Cloud SQL have a built-in method to export your data to cloud storage. Aurora’s is an SQL command, whereas Cloud SQL’s is an API command.

DevOps

All services allow you to manage your MySQL servers using native infrastructure-as-code tools, such as AWS CloudFormation, Azure Resource Manager, and Google Cloud Deployment Manager.

All services are also supported by third-party services, such as Terraform.

Security

Since it’s MySQL afterall, all services allow you to use MySQL authorization and authentication. Amazon RDS and Amazon Aurora though also add IAM authorization. So you can link database access to your AWS account access users/roles.

All services provide infrastructure protection using IAM authorization.

And all services provide optional SSL support with optional enforcement to keep data private during transmission.

Disclosure

For Skeddly, I’m using an Amazon RDS for MySQL db.m5.xlarge MySQL instance in a Multi-AZ configuration.

Final Thoughts

If starting a new project today, I’d start with Amazon Aurora (or Aurora Serverless). But due to the risk of behaviour differences, I wouldn’t migrate an existing database unless there’s a need.

For the remainder of the “true MySQL” options, I don’t see a clear winner over the others. It’s going to depend on which features you care about (or don’t care about), and if you’re already using a particular cloud provider.

About Skeddly

Skeddly is the only all-in-one scheduling and automation service for your cloud. Only Skeddly can lower your cloud bills and manage your cloud backups in one place. Customers are happier knowing that Skeddly is working for them in the background.

Start managing your AWS, Azure, and GCP accounts today. Sign-up for our 30 day free trial or sign-in to your Skeddly account to get started.

By Matt Houser on Jan 14, 2020 in Comparisons, MySQL, Amazon Web Services, Azure, Google Cloud Platform | Permalink