Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

MySQL-Compatible Cloud Database Cost Comparison

DZone's Guide to

MySQL-Compatible Cloud Database Cost Comparison

Find out the costs of AWS RDS for MySQL, AWS Aurora, Cloud SQL from Google Cloud Platform, and Microsoft Azure Database for MySQL and see how they compare.

· Database Zone ·
Free Resource

MariaDB TX, proven in production and driven by the community, is a complete database solution for any and every enterprise — a modern database for modern applications.

As a database vendor whose drop-in MySQL replacement database runs on-premise and on any cloud, we are often asked by our customers to guide them through a MySQL-compatible cloud database cost comparison.

We have discovered some hidden hard and soft costs that are important to consider. In this article, we will share some of our learnings and a MySQL-compatible cloud database cost comparison model that we hope will be helpful to those looking at using a MySQL-compatible database to run in the cloud and planning to do a MySQL-compatible cloud database cost comparison.

We will compare the costs of the MySQL-compatible offerings from the four leading cloud vendors: AWS RDS for MySQL, AWS Aurora, Cloud SQL from Google Cloud Platform, and Microsoft Azure Database for MySQL. In this MySQL-compatible cloud database cost comparison, we will look at costs for a baseline three-zone architecture and then a scaled three-zone architecture with higher throughput requirements. But first, let’s makes some assumptions about our application requirements.

MySQL-Compatible Cloud Database Cost Comparison

Application Requirements

We will define the application database requirements as follows:

  • Baseline three-zone
    • Average of 5,000 transactions a second
    • Peak of 10,000 transactions a second 2% of the time
    • A read-write mix of 90:10
    • 7500 I/Os per second
    • 1TB of storage — requiring 1.25 TB on an ongoing basis
  • Scaled three-zone
    • Average of 15,000 transactions a second
    • Peak of 30,000 transactions a second 2% of the time
    • A read-write mix of 90:10
    • 22,500 I/Os per second
    • 1TB of storage — requiring 1.25 TB on an ongoing basis

Level Field Assumptions

For the purposes of this MySQL-compatible cloud database cost comparison article, let’s make some assumptions to create a level playing field.

  • Scalability: We’ll assume that the target application has scalability requirements that exceed the capacity of a small instance and require 32 cores at a minimum and that each of these databases will scale to the level we need using the scaling method they recommend.
  • Ongoing administration costs: Every cloud database has database and administration features they tout as being valuable. For the purpose of cost comparison, let’s assume that these capabilities are equivalent between vendors and any features one lacks are compensated by its own features the others lack.
  • Backup costs: For the sake of model simplicity, we will not include backup costs since there are a variety of ways to accomplish this with any database.
  • No egress: We’ll assume that the traffic between database and application stays within cloud service, so there will be no egress charges.
  • Eastern-region pricing with annual commitment: To take advantage of the price advantages of a reserved instance, we will assume a one-year commitment and use eastern-region pricing for each.

Baseline Three-Zone Architecture

Our first comparison will be for the MySQL variants with three 32-core nodes across three zones within the same region. The three nodes serve the following functions:

  1. A read/write master
  2. A read-slave
  3. A replication for a hot backup in case of a failure in the zone with the master

MySQL-Compatible Cloud Database Cost Comparison Figure 1

The following table lists the servers and associated costs for each cloud database given the application requirements and workload defined above.

MySQL-compatible cloud database cost comparison table #1. Three zones with one instance each:

MySQL-compatible cloud database cost comparison table 1

Scaled Three-Zone Architecture

Now let’s look at what happens when you need to scale the application’s workload. For MySQL and its cloud derivatives, the required scaling approach is sharding, so we will expand the database into three shards with one shard in each of the three zones.

As you shard, you will need three master servers. Matching the requirements above for the three-node architecture, each master will have one read slave plus one backup slave.

Therefore, the total servers will be:

  • 3 read/write masters
  • 3 read slaves
  • 3 backup slaves

MySQL-compatible database cost comparison figure 2

Now we will look at the costs associated with each.

MySQL-compatible cloud database cost comparison table #2. Three zones with three instances each:

MySQL-compatible cloud database cost comparison table 2

The Hidden Costs

As you can see, when doing cost comparisons for MySQL-compatible cloud databases, costs start to add up significantly as your application gains traction and your workload and database size increase. Beyond the cost of each instance, there are additional items to consider when planning the long-term TCO for your application database.

Hidden Hard Costs

The tables above make the hidden hard-costs not so hidden anymore. They include:

  • Storage
  • I/O
  • HA: Replication instances dedicated to hot-backup and recovery, which are not contributing to handling the production workload of your application

Hidden Soft Costs

There are also some soft costs that you will need to consider when looking at your overall TCO for these cloud database. While only you know how to estimate these costs specific to your business, they are important to consider when costing out cloud database solutions.

  • Development costs: Sharding requires intelligence to be embedded in the application code to interact with the shards and handle data integrity. You will need to consider the costs of the additional development effort to modify the application so it can leverage the shards of data in your initial release — and the costs of maintaining that additional logic in all future releases.
  • Opportunity costs of delayed features: Since creating a sharded environment can take many months to a year, application features will most likely be delayed as developers modify the code to address the sharding. If the application is consumer-facing or business-critical, there is always a price to pay for delayed features, either in delayed user adoption or inefficiency for the individuals using the application.
  • Database administrator costs: Since scaling beyond one read/write master requires sharding for each of these cloud database offerings, you will need to add in the costs of employing database administrators to conduct the sharding and to maintain the complex sharding environment as the application changes going forward.
  • Cost of moving to a new cloud infrastructure provider: Since these databases have varying degrees of MySQL and ANSI-SQL compatibility, your application will need to be tailored to each database. This will restrict your options to move to different cloud vendors or databases — or cause significant application rewrites — if the need arises. In addition, most cloud vendors will charge you for moving your data from and to their platform. These need to be included in your TCO calculations.
  • Cost of downtime as a result of failure: The architectures above all continue to have a single point of failure. There is a business cost associated with applications being down due to lost customers or business processes being put on hold. Be sure to consider these when making a purchase decision.

MariaDB AX is an open source database for modern analytics: distributed, columnar and easy to use.

Topics:
database ,cost comparison ,mysql ,compatible ,cloud database

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}