Insert pithy witticism here
Why would people pick MySQL in the first place? Because "everybody else does it", and they don't know any better. As the M in LAMP it sees a lot of automatic deployment even if a different approach might've been a better idea. It happens.
Why would people move to NoSQL? Because it's the hype du jour, or they (think they) need "web scale" or other applications that if you would try to tackle them with "traditional SQL" you risk running head first into a brick wall of conflicting requirements. Or maybe because you can get better performance with comparable guarantees if you're willing to put up with the fiddlyness that's inevitably part and parcel of the relative immaturity of the new field.
Why would people move from MySQL to PostgreSQL? Because they realised they really do need guarantees like ACID, which MySQL only "follows"*, not actually really completely provides. And half a guarantee isn't a guarantee, even if most casual use is almost certain never to run into the corner cases where MySQL drops the ball.
So the field is changing. Is this a bad thing? By no means. MySQL is a nice hobbyist tool with bells and whistles and things. It serves lots of basic tasks pretty well. It even scales to a certain degree, thanks to lots and lots of people pushing it onward. But if you need something better, well, you need something better.
I disagree it's getting harder to choose, actually. You can still pick MySQL, or anything else you fancy, and hope to the skies above that it's good enough. Since the field tends to improvement the chances of picking something that'll be reasonable close to good enough are continually improving. And if that doesn't work you can (nearly) always throw more hardware at the problem until it goes away, and that happens often enough too.
The way to get a really good fit is still the same as before: Understand the problem, the sort of queries you do on what sort of data and so on, understand the theory of operation, and let your choice be driven by your requirements. With ever more options, the chances are there'll be one or a few "close enough" and maybe some will be open source too.
The problem then is more that you have to understand enough of the various options to make an informed choice. Since most of the NoSQL wave are more or less niche products, you can ignore them if you're in a different niche. That then leaves the more generic ones to choose from, and if you are informed you can make an informed choice.
As a trendwatching piece the article is a tad pathetic. CIOs shouldn't worry about this sort of thing. They should instead be hiring people who bring the right know-how to their projects and who'll pick the right tool for the job. Which, short of projects that are indeed best served by yet another LAMP stack, rarely would be MySQL. But then, there's still CIOs that hire MCSEs and A+ certificees, so MySQL will have a future for quite a while yet. No, MySQL was never my first choice, as you probably can tell. Popularity alone doesn't get the job done, and when all's said and done, it's the work that counts.
* That's what the manual says. It also says that constraints clauses are parsed but ignored. That chucks the C in ACID right out the window. If you need constraints at all, you need something that can provide that functionality reliably, not just when it feels like it.
Biting the hand that feeds IT
