Everything You Need to Know About Scaling MySQL – Part 3: Your Options

It’s safe to say that 20 years ago, when MySQL was developed, programmers working on the project likely were unable to predict the extremely pervasive nature of today’s Internet. As such, the open source relational database management system was built with severe limitations—though, at that time, those limitations were merely theoretical.

Nowadays, thanks to the rise of e-commerce and m-commerce, those limitations are manifesting themselves more frequently than ever before. As more and more customers become digital-first shoppers, e-commerce websites are seeing more traffic than they’re used to handling. While MySQL databases might be able to handle all your users right now, for example, there’s a good chance they will hit a wall somewhere along the line when they scale from 200% to 300% and beyond. When that happens, your website will stop working properly, which means you can’t make sales and your frustrated customers will take their business elsewhere—perhaps permanently.

With MySQL, after a write-master has been scaled up to the largest instance available, those wishing to improve their site performance have traditionally had two options:

  1. Replatforming. As the name suggests, replatforming is the process of migrating your e-commerce database from one solution to another, like moving from a Magento/MySQL implementation to an Oracle-based one. As you might imagine, such a process is complicated, generally involving large rewrites of code, representing a large time and cost spend. On top of that, replatforming can be a risky process, too. If a problem occurs during the process, your site could be offline indefinitely, or worse- your data could potentially be wiped out.
  2. Sharding. Another option is sharding, wherein a database is partitioned across multiple servers. While this method serves as a workaround to improve MySQL performance, sharding presents significant drawbacks. Because your dataset is now literally ‘split’ between multiple separate databases, the power of the relational database management system to guarantee ACID Compliance is lost. That means now your application must be rewritten significantly to ensure your data remains uncorrupted… and hope that your application programmers successfully ‘reinvent the wheel’. And to top it all off, now your database just became much harder to manage, requiring more DBA support costs.

While replatforming and sharding are two ways to improve MySQL performance, they’re both difficult processes that are costly and time-consuming. Luckily, they’re not the only options for those looking to improve the performance of their sites.