Eight Sound Reasons Not to Use MySQL

In the time I’ve served managing a technical consulting firm, I’ve heard my share of excuses for not using MySQL. While many of these reasons were based on misconception, there are a number of sound reasons not to use MySQL. These will, of course, vary from one situation to the next, but in each context, I suggest that rather than rely on the opinion of a jaded database administrator (DBA), the rejection of any database technology should stick to the legitimate reasons. To that end, in this article I outline eight sound reasons not to use MySQL.

First, the reasons not to use a given technology are not of the same nature as the reasons to use it. Often the reasons to avoid something are more compelling. We might need several reasons to actually use the technology, but it may take just one to stop us in our tracks. The selection of software is one such decision; a single reason is almost never adequate to trigger an affirmative decision, but a single strong negative overrules a dozen good positive factors.

Also See…

Five Compelling Reasons to Use MySQL

While there is a long list of relational database management systems (RDBMSes) from which to choose, I restrict comparisons to a few of the most common. Many technical comparisons exist, although comprehensive recent ones are fewer in number. Here we concern ourselves with the “big-picture” reasons.

MySQL Uses the GPL

The biggest one first. This isn’t the time or place for a GNU General Public License (GPL) flame war and typically, neither is the selection of database technology. Clearly a GPL license is a plus for many, but for some environments, GPL’d software is a non-starter. In these situations, if the BSD license of PostgreSQL is still too “open,” a commercial license is preferred.

MySQL Doesn’t Use the GPL

In some instances, MySQL is non-free, and the GPL may not serve those situations well. If you want to distribute the license for the database along with your own project, your project must either be licensed under a similar compliant license, or you must pay for a commercial license. If this factor changes the way that your software is distributed, you’ll need to cope with the added burden of supporting your product on multiple versions or configurations of MySQL, or (if it otherwise increases the cost to the end user) there may be an undesirable bottom-line impact caused by MySQL’s use. In these circumstances, some software distributors may tend to opt for an alternative such as PostgreSQL under the BSD license.

Integration With an Existing Environment

I know of one large IT shop that has site licenses for Oracle and Sybase, and a number of specific licenses for MS-SQL Server. In this shop, the MS-SQL instances are largely the result of the ignorant department staff who don’t know they paid for site licenses for other databases. The addition of MySQL (or any other database) is an unwise idea in this context, given that the DBAs already have enough environments to deal with. In situations with pre-existing database environments, it is pretty much axiomatic that the management burden is diminished if a common platform can be maintained. Further, if the company already owns licenses to a proprietary system, one of MySQL’s major strong points is negated.

Product Maturity

By way of comparison, Oracle will hit the 30th anniversary of its first product shipment in 2009, at which point MySQL will not yet have hit half that distance from its first release. For its part, Microsoft SQL Server is only a couple of years older than MySQL, but its first release was based on Sybase, which was at that time six years past its first release. As for the other notable open-source database, PostgreSQL will in 2009 hit the 20-year mark from its first release. While MySQL is not the newest database on the market, there are older, more established alternatives—and for many, that’s reason enough. To be fair, this is in my view not a particularly strong reason to opt against MySQL, but at the same time, I’d be hard-pressed to tell a conservative IT manager making a platform decision for a mission-critical application based on this factor that he’s doing the wrong thing.

Feature Set Maturity

While some are tempted to compile an overview feature comparison of MySQL versus other systems to use as an authoritative decision-making tool, in many respects this is a mug’s game. As new software releases or patches are issued by any of the vendors, the list becomes rapidly outdated. Further, features that are important to some applications have no relevance to others, such that “10 percent more features” is really a measure of no consequence. What does matter is whether the feature set at the time of release matches the requirements, or matches closely enough.

Sometimes, you can compensate for missing features with workarounds, such as a join instead of a subquery in MySQL prior to version 4.1. Most of the required features for an RDBMS are firmly in place with the release of MySQL 5.0, but we can legitimately consider the maturity of some of these features as a possible reason to shy away from MySQL. For example, the lack of views, triggers and stored procedures has historically been the major criticism of MySQL. These have all been supported by MySQL for a year or so now, but by comparison, they have been features for about 10 years in most competing RDBMSes.

Sure, the development cycle from the MySQL team is, in many ways, impressive. However, if the user’s temperament is particularly gun-shy toward new technology, the longer-supported feature is the more certain bet. In this case, these three major features are still relatively recent additions. Even as of MySQL 5.0, ACID (Atomicity, Consistency, Isolation, Durability) consistency is not guaranteed in the case of a crash when some kinds of stored procedures or functions are used to modify the database. (See Binary Logging of Stored Routines and Triggers.)

Availability of Certification

Some IT shops love certification. While MySQL does have a certification training program, its training availability is not nearly as widespread as for, say, Oracle or MS-SQL Server. In broad terms, even if IT staff with MySQL are relatively easy to come by, certification or ongoing training remains less so, with fewer third-party training sources available. For larger IT shops, the enterprise experience that typically follows the commercial database systems is also desirable, while some people with MySQL experience may have less depth.

A related issue is the availability of qualified third-party support. While the availability of support services directly from the vendor mitigates the issue, to some degree, the same factors apply if strong local on-site support is required from a third party.

Corporate Considerations

Oracle, Sybase and Microsoft are all publicly traded companies. Whatever one might say about the strength of MySQL’s backers, the fact that the company is not publicly traded means the financials are not required by law to be a matter of public record. At the risk of being accused of spreading FUD (Fear, Uncertainty and Doubt), the relative transparency of a publicly traded company (rightly or wrongly) provides certainty, stability and security to some IT managers and those to whom they report. The old saying about nobody ever being fired for buying IBM applies here (even if IBM recently decided to start selling MySQL); dealing with a large reputable corporate entity does tend to help some people sleep at night, be they investors, PHBs (Dilbert reference: Pointy-Haired Bosses) or experienced IT managers.

Perception of Scalability

I’ve titled this last reason carefully. There is a fairly consistent perception among many industry professionals that MySQL doesn’t scale well. This matter is debated by some, though most debates tend to munge the difference between scaling up and scaling out (vertical vs. horizontal). MySQL discusses scaling out more than scaling up, but lists scalability as one of the top reasons for using MySQL.

One trend I have observed but for which I have no hard data is that formally trained DBAs tend to prefer a proprietary RDBMS such as (most commonly) Oracle. I suspect that those with formal training and experience as a DBA (rather than as a software developer) tend to have a bias toward proprietary systems. In a larger environment with a defined role for a DBA (as opposed to a part-time consultant or someone doing double-duty as a developer), MySQL is likely to find less favor for this reason. Whether the scalability of MySQL is a real or imagined criticism becomes irrelevant at precisely this stage. Barring a strong reason to override this factor, when you have talented resources at your disposal, you want to give them the tools with which they are most comfortable and can get the most mileage. If your staff DBA with 15-plus years’ experience wants Oracle and it’s in the budget, do it; this approach always pays off in the long run.

There comes a point when comparing stable, mature, feature-rich products that one tends to stop obsessing about which one is “better” in an absolute sense. In place of this question is one that requires more insight: which one is more appropriate to a given situation. I think the leading RDBMSes have all reached this point now, including MySQL. The question of when this occurred may be open to some, and those few are welcome to conduct a debate on the matter. Suffice to say that this is the landscape of today, and with no slight to any of the leading systems, there are specific times to opt against the use of each. In the case of MySQL, I believe we’ve been able to cover some of the strongest ones—those that are not simply one version-release away from becoming outdated.

Now that you’ve read the reasons not to choose MySQL, be sure to read the alternate view: Five Compelling Reasons to Use MySQL.

Brent Toderash recently left the IT consulting firm of which he was an owner and manager to become a freelance writer, thinker, strategist and consultant. Founding editor of Penguinista.org, which he ran from 1999-2003, he lives in Winnipeg, Manitoba, blogs at toderash.net, guides several Web projects built on MySQL, and remains enough of a geek to have written this entire article in vi.