So your app is using MySQL as the backend, and you’ve hit a few performance hiccups. Maybe you’ve even hit straight up roadblocks. And right now you are wondering if you have hit the wall with capacity for MySQL and are asking yourself if it is time to do something really drastic, and really painful, or if there is a smarter way to give your app more runway on its data store.
First of all, we’re sorry you are in a tight spot. We’ve been there, and we feel for you. In fact, our company was founded just to deliver a drop-in replacement for MySQL that does truly scale-out, and harness the power of distributed computing. But ClustrixDB is not for everyone, and no one recommends moving your data unless you really have to in order to survive.
We have these conversations all the time, so we thought we would walk everyone through how we think about the trade-offs for the various scaling strategies for MySQL.
In this video, we will answer:
- What measures tell you your MySQL deployment is hitting capacity?
- How can far can you improve your MySQL capacity with hardware?
- How can architectural changes like sharding, read slaves, and master/master replication expand capacity?
- When is it time to replace MySQL with something else?
Check it out below.