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. For this process, we have learned it is important to compare the total cost of ownership (TCO) of deploying ClustrixDB on different cloud platforms as compared to the MySQL-compatible offerings from the leading cloud vendors, such as AWS, GCP, and Microsoft Azure.
We have discovered some hidden hard and soft costs that are important to consider. In this blog, 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, 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
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 blog, 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:
- A read/write master
- A read-slave
- A replication for a hot backup in case of a failure in the zone with the master
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
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
Now we will look at the costs associated with each.
MySQL-compatible cloud database cost comparison table #2. Three zones with three instances each
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:
- 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.
ClustrixDB Handles Same Workload with Fewer Nodes
Now we’ll take this same MySQL-compatible cloud database comparison model and look at accomplishing the same with ClustrixDB on each cloud vendor. With ClustrixDB, every node can be a fully functional database with read/write capabilities, so there is no need for read slaves or reserving a node for replication to provide HA. And since ClustrixDB scales-out horizontally, we recommend ClustrixDB be deployed on multiple 8-core servers instead of a single 32-core server.
We will use AWS as our cloud vendor for this model, since the prices between the four vendors will be similar and ClustrixDB is not subject to the hidden costs of I/O or storage. Since ClustrixDB does not need to scale “up”, we can use i3s instead of r3s, which have the same generation CPUs.
To have an equivalent amount of computing power, for the baseline architecture, we will model four 8-core nodes across three zones for a total of 32 cores. For the scaled architecture we will model twelve nodes across 3-zones for a total of 96 cores. Therefore matching the MySQL-based architectures above.
My-SQL Compatible Cloud Database Cost Comparison table #3. ClustrixDB on AWS
* Standard volume discounts applied
Hard Cost Savings with ClustrixDB
As you can see, in terms of hard costs, ClustrixDB comes out less expensive on an annual basis than all of the MySQL-compatible cloud database competitors other than AWS RDS for MySQL. It’s important to note that with the ClustrixDB configuration you are not wasting any computing power and associated dollars on:
- A replication node for failover
- Read-only slaves
Therefore, ClustrixDB requires fewer nodes while still maintaining the three-zone HA protection.
Soft Cost Savings with ClustrixDB
In addition to the hard cost savings demonstrated in table 3 above, ClustrixDB provides significant soft cost savings.
Additional savings with ClustrixDB:
- No development costs: ClustrixDB is a drop-in replacement for MySQL and scales-out, so sharding and its associated development is not required.
- No opportunity costs from delayed features: ClustrixDB will not require you to rewrite your MySQL application to accommodate sharding.
- No additional DBA costs: ClustrixDB is self-managing and there is no sharding.
- No costs moving to a new cloud infrastructure provider: Your application and database can move from one cloud vendor to another without additional development, you will just pay the cost of moving your data the cloud vendor requires.
- Reduced likelihood of downtime costs: Since ClustrixDB has no single point of failure, any of the nodes can continue to carry on if a node, or even a zone, goes down.
As you can see, doing a MySQL-compatible cloud database cost comparison is very important before you make a purchase decision. If you are looking to move your MySQL application to the cloud or considering moving from RDS to one of the newer MySQL-compatible cloud databases, we encourage you to talk to us at Clustrix. Our team will be happy to guide you through a comparative cost model specific to your application and business to see how much we can save you. And of course, we will share some of the innovative scale-out and self-managing features ClustrixDB can bring to your OLTP application that will make your life much easier.