Once vertically scaling your databases can’t help you any further you need to think about sharding them. Sharding basically means you are going to distribute your (write) workload over multiple database hosts using an algorithm. For some OpenSource Databases, you get sharding out of the box, but for MySQL, you don’t.

This means you either implement a sharding yourself and have absolute control over what data goes where or choose an out of the box solution like Vitess.

When MessageBird hit the limits on one of our cornerstone databases, we had to implement a sharding solution fast. With strong time constraints at hand, this meant we had to act fast and created our own sharding solution. Luckily we were able to reuse most of our existing infrastructure for this purpose. However, once it was time to shard another database, we took a step back and evaluated whether we should use our own solution once more or pick a sharding platform like Vitess.

In this talk, I’ll take you through the good, bad, and ugly of sharding, the choices you have to make, and the obstacles you can expect during your journey.

Related Videos: MySQL, Performance Optimization

Using PMM to Identify and Troubleshoot Problematic MySQL Queries
Google Cloud Platform: MySQL at Scale with Reliable HA
Analytical Queries in MySQL - PLO October 2020
MySQL Ecosystem on ARM - Krunal Bauskar - Percona Live ONLINE 2020
How Does Geo-Replication Work in TiDB? - Jay Lee - Percona Live ONLINE
SQL Row Store vs Data Warehouse: Which Is Right for Your Application? - Robert Hodges - PLO October 2020
Introducing Kunlun Distributed Database Cluster - David Zhao Wei - Percona Live ONLINE 2020