MySQL Scalability

Patryk Golabek
CTO/Software Architect at Translucent Computing Inc
Since we have MySQL specifically, and we have to use it in many different environments, dev, testing, and production. All those different people are using it. Developers, QAs, automated testings running against that. In production we have many different users, so we have different meaningful products that are already running. For example, It's a loan application site in Canada that is serving a lot of users daily and is backed by MySQL and Elastic SQL databases. So we're using it for high volume and low volume. We have it in many different projects and many different environments. We use it in different environments, the production also, and many different products as well. We do have plans to run everything as a cluster, and probably will slowly switch to MetaDB. That is something we're doing right now. We also have plans to switch it to the managed version as well for production deployments, for the simple reason that we're trying to offload as much as we can from the DevOps people. So if offloading that management database from them will help them, then we'll do it. Also, there are clients that have preferences when it comes to where the database should be running. For example, one of our major clients wants to run specifically in our database because we built it for them and they're comfortable managing it. You're always more comfortable having a managed version. So if you have a small team with a managed DBA, even though it's more expensive and there's always some issues coming up with it, you can just let Amazon manage it for you, and you don't even have to think about it. You could do the backups and if something happens, they can restore it. And you can scale as much as you want, as well. In terms of cost, there are different flavors of it. It depends on the solution. Locally, as I said, MySQL is going to stay the way it is right now. We're not going to have a cluster version, because for development we just need a database. You need to have a scalable database or clustered. So MySQL is going to change. We're in the process of transitioning the production versions to cluster versions for some of the projects because they have more volume. We can see that because of the volume of users, and how many queries they do on a daily basis, they would benefit from having a cluster versus a SQL database. So you can have a master to master cluster, which you can have separately. You can actually manage your read and write separately, and then optimize. So you can give more power to people, to certain queries, spreading across the cluster. So all those sorts of things come with the cluster database. That's going to improve performance. One of the things that we're doing is looking at the short version of MySQL, which is a new thing. This means a shared database. Elasticsearch is made up of shards. This is a different way of thinking about relational databases like MySQL. Traditionally, MySQL or relational databases, have been crafted by having an instance of equal slave to equal master. You have many slaves and many masters, as well. Now the sharding makes the database a little bit different, and it's more usable for us in terms of the way we deploy things. So we're looking right now at MySQL sharding as well, and a few of the different flavors of that so that we can scale it horizontally. Instead of actually creating an instance of MySQL, we can actually spread across multiple different shards across many instances. And it's also cheaper as well. Once you start getting into the shard world, it's really cheaper to deal with some of these issues, like clustering issues. So it's more cost-effective. View full review »
CCO at a construction company with 11-50 employees
According to our experience, it's not really an enterprise tool that you can easily expand and scale the way you can with, for example, Oracle. It's good for small to medium-sized applications. It is not ideal for very big applications. We have a data center that uses the application and it isn't very heavy on traffic. It basically runs on its own. We only use it occasionally. It's like a co-operation management system. We do plan to increase usage, but we plan on looking at different databases. We're in the process of researching how scaling up would work. Chances are, we'll need to move to a different platform. View full review »
Grégory Tabourin
Infrastructure Platform Engineer at a cloud provider with 51-200 employees
The scalability of the solution is good. We haven't had trouble scaling at all. View full review »
Learn what your peers think about MySQL. Get advice and tips from experienced pros sharing their opinions. Updated: April 2020.
419,794 professionals have used our research since 2012.
Partner at a tech services company with 51-200 employees
If the user sets up DB up using MySQL Cluster (creates a grid type of design), then we find the solution from a hardware perspective using NVMe, NVMe-oF, 10GE network connections, and 32-100GB of DDR4 memory (dependent upon customer requirements). Scalability can be initiated using high-speed connections across IPv6 connections (IPSec AES-256 ESP/AH VPN connections without purchasing VPN concentrators — this can be done at the network layer). View full review »
Business Intelligence Manager at a translation and localization position with 501-1,000 employees
We haven't experienced any issues with scalability. View full review »
George Otako
CEO at OS Labs
Scalability is good enough. View full review »
Learn what your peers think about MySQL. Get advice and tips from experienced pros sharing their opinions. Updated: April 2020.
419,794 professionals have used our research since 2012.