On Choosing Not to Use MySQL

I’ve written an article called “Eight Sound Reasons Not to Use MySQL” which has been published on CIO.com today opposite Tina Gasperson‘s article, 5 Compelling Reasons to Use MySQL. The topics were assigned, not so much as a point:counterpoint but as a way of presenting views from both sides. If you haven’t read it yet, give it a look. If you did that and followed a link based on that article to find me here, welcome. What you’ll find around here isn’t all tech-speak, there’s a lot of management and marketing stuff as well… and you’re more than welcome to hang around a while and poke around, subscribe, whatever. Let it be known that there are a few things I want to say about the article though.

Given the publishing website’s title of “CIO,” my piece was not aimed at the “geek-in-the-trench,” and when the article appeared on Slashdot, I didn’t fare that well with the peanut gallery. I knew that I was drawing the “bad guy” card when I got the assignment, but I forged ahead anyway. I guess if I’d have thought about it I would have realized that the piece was definite Slashdot-bait, but that crowd isn’t necessarily a good one to write to, and they’re not the intended audience. But I do have some random thoughts relating to the article and some of the general reaction to it.

First up, let’s get it out of the way: I’m not anti-MySQL. I love MySQL, and this site runs it because it’s the best thing for this particular job. I’ve told a lot of other people they should use it. But this does not mean it’s the best thing for every job, which is why I can stand by what I wrote in describing when not to use it. I might rather have tackled the pro reasons, but I still wouldn’t say one should always use MySQL. Put it this way, even if TechnoWidget-4.2 is your favorite tool, any IT practitioner who cannot or will not appreciate that there are situations where other tools might be better choices simply isn’t worth his salt.

Next, yes I know, the first two reasons contradict each other. I thought about combining them into a single reason, “licensing,” but it would still have contradicted itself — and if I’d written the pro reasons, licensing would have been one of them. Yeah, I know, it’s difficult. The point is that not every situation is the same. Some situations require an open license, some require one that isn’t, and some are neutral. The same fact therefore becomes a feature in one instance, a failure in another, and simply irrelevant in a third.

The article follows some specific logic and is written from a particular angle — and the article is clear about this. First I said,

…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…

Next, I was clear at more than one point that I wasn’t doing a technical comparison, which I said for an overview article was a bit of a mug’s game. At the beginning, I said, “Many technical comparisons exist, although comprehensive recent ones are fewer in number. Here we concern ourselves with the ‘big-picture’ reasons.” At the end of the article, I said,

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.

Basically I’m saying,

  1. A lot of reasons I’ve heard for not using MySQL are bad ones, but
  2. this is not a technical article. Remember,
  3. situations vary and these reasons aren’t universal. Just any
  4. one reason may be enough to reject the use of MySQL (or any other RDMBS), because
  5. MySQL isn’t right for every situation, even though
  6. MySQL is a very good product that stacks up well against other major RDBMSes.

Some of the Slashdot kiddies should really go and grok the piece a little better… but I know, it’s easy to get confused when following a personal “RFRL” policy… was that, “Read first, respond later, or Respond first, read later?” There are several good comments in the thread when people discuss a specific point. But so far despite all the bombast, nobody (as of this writing) has engaged the piece at the level or audience for which it was written.

It might look like I’m kicking everybody’s favorite puppy… but I’m not. Some people are just allergic to dogs, afraid of dogs, or already have cats. And in some situations, [insert any RDBMS name here] is not the best choice for the job. That’s the real world, and to master it you need to learn to tell which situations are which. And without trying to be completely rude, that’s the expertise that’ll get you out of the peanut gallery and into the good seats.

Update: (March 26)
I was a bit snarky with the Slashdot folks at the end of this piece… more than I intended really, but hey — this is my platform, I can say what I want. I haven’t changed it because I generally don’t pull posts once they’re out “in the wild,” I just may add an addendum like this, flagged as such… but generally, you’re stuck with what you say online. My article was not technical, didn’t pretend to be… and I’ve gotten good positive feedback from the quarters who put it into its proper context. Now that the Slashdot thread (link to comments ranked 4+) has gone on a bit, anyone wanting a technical discussion should look there. If I wanted a strong technical reason, it’d be the one I hinted at… the right kind of scalability; but that’s out of scope at the moment. And now that I look again, it dawns on me that the piece is filed under “Developers” — Slashdot doesn’t have an “IT-Management” category, just a general “IT” one. But still, there are some commenters who seem to get it a little better now, even if some suggest I’m spreading FUD (which I mention in the article), though that commenter has actually read and engaged with the article.

I like Slashdot, but I don’t go there for management advice. (You can quote me on that.) In case there’s any doubt left, the matter has become an illustration of why some of these IT decisions are difficult, and management can be at odds with the IT staff, and this becomes instructive. (Maybe I’ll write more on this at some point.) Some of the IT staff are incapable of ever putting business decisions before technical ones, and sometimes that’s precisely what needs to happen. Dare I say it again? That’s the expertise that’ll get you out of the peanut gallery and into the good seats.