Well, as one of the business customers who pays for MySQL Enterprise, I can tell you why we pay for MySQL. Because when our company was much smaller, and we needed a SQL server, we chose to go with MySQL because it was free, because a lot of people use it, and because some of our developers had experience with it. If we’d have been a little bit smarter at the time we would have chose Postgres, but that’s water under a bridge. So we built up our company based on MySQL, and our company grew and grew. Eventually we grew to the point where we had locking issues with our MyISAM tables. Table level locking just didn’t provide the concurrency we needed for our services. We then moved to InnoDB tables, which gave us the concurrency we needed. We eventually bought the InnoDB Hot Backup tool for ~$999 a copy, because the hot backups beat the dumps we were doing on our slave SQL servers. Fast forward five years. Our company is much bigger and much more profitable. We have plenty of budget to buy any SQL server we need.

However, we’re stuck on MySQL because MySQL currently hosts all of our tables. Moving all of our tables en mass is simply unrealistic. We have too many clients and the downtime would be severe. When we move databases over, we have to move everything that is JOINed in any query. Most importantly, for a majority of the time that we’ve used MySQL, they had no stored procedure support. Therefore, all of our applications have hundreds of hard-coded queries and associated logic. Without the abstraction layer provided by stored procedures, moving our databases requires rewriting all of that code. Even worse, the hard-coded queries contain many MySQL-isms (MySQL specific syntax) and depend on MySQL behaviors, like the idea that there’s a date 0000-00-00 00:00:00. Obviously there is no such date, but you’ll find many MySQL databases which contain a DATETIME field and use that “0” instead of NULL. When you try to store that date on other SQL servers, or when you try to fetch that date into a typed variable in certain languages like .NET, obviously they don’t allow their date/time type to contain invalid dates/times and therefore you get an exception.

I could go on and on about the issues trying to port legacy MySQL code, but the basic fact is, without stored procedures to encapsulate their vendor specific extensions, behaviors, and syntax, we have neither a hope nor a prayer of moving away from MySQL. MySQL 5.0 provided very basic stored procedure support, and we are using this as our chance to finally escape, but it’s still a huge process.

Now, why are we so desperate to leave MySQL when they’re the SQL server that helped us build five years of solid success and amazing growth in our company? For precisely that reason, we’ve grown. And as we’ve grown, the load on our MySQL server has grown quite a bit. So we provisioned some powerful hardware to give MySQL the CPU, memory, and disk power that it needs to do what we ask of it. But behold, our effort to give MySQL more power failed. MySQL’s only production-ready engine to provide the concurrency we need (MVCC or row level locking) is InnoDB, and InnoDB’s scalability is limited when it comes to a modern high end server like a dual cpu quad core. And so we wait for MySQL to patch, and we wait for InnoDB to patch, and they have patched some. They’ve made some improvements. But we’re still limited in how much stress we can put on a server that can’t even begin to use its 8 cores due to lock contention and design issues.

So basically, we can’t scale up, and we can’t easily port to another platform, both due to the limitations of MySQL. And yet, the simple fact is, despite its limitations we desperately need the best MySQL we can get with the latest performance/scalability patches, and the newest bug fixes. And *that* is how MySQL gets our money. We used them as our gateway database until we grew to the point where we’re now stuck with them. Being stuck with them, we pay for the best support plan we can, and use the latest MySQL Enterprise we can.