There's an interesting post over at Olery's blog about a successful migration story from using MySQL/MongoDB to PostgreSQL as the persistence layer for applications that, however, lists a couple of cons of using MySQL that I personally think are no longer valid complaints (or at least not as big as they used to be). I did not find a way to reply to the post so, hopefully for the benefit of people who are new to MySQL and may hear the same recycled myths, I am doing so here.

Now I am aware that PostgreSQL has feature MySQL lacks (bitmap indexes are a personal favourite), but still, it is frustrating that instead of using actual arguments consisting of actual use cases in which one database is better than another, these old stories get recycled. I think it's a disservice to both MySQL and PostgreSQL.

The first paragraph that caught my attention is:

MySQL was the first candidate as we were already using it for some small chunks of critical data. MySQL however is not without its problems. For example, when defining a field as int(11) you can just happily insert textual data and MySQL will try to convert it.

The sql_mode variable is available since at least 4.0 (GA in 2004 if I'm not mistaken, which is over a decade ago) and while yes, the default value is permissive, and any evil programmer will be able to change the value for the variable (Roland made very good suggestions about this some time ago), in my experience it has provided people with enough protection against this kind of data integrity problems.

And here's the second one:

Another problem with MySQL is that any table modification (e.g. adding a column) will result in the table being locked for both reading and writing. This means that any operation using such a table will have to wait until the modification has completed.

Innodb supports some online DDL operations starting with MySQL 5.6 (GA in February 2013, over two years ago) and of course, there's always pt-online-schema-change, which can usually help in the cases were online DDL is still not supported, or when the impact on replica lag makes that approach unfeasible.

To wrap up, my message is that it's a big world out there, with different technologies that all have cons and pros. You need to make your due diligence and investigate the biggest of each when evaluating one technology, or comparing a few of them, to make sure you pick the best tool for the job (and for your context, because tools are not context-free. A kitchen knife is not a very good screwdriver, but a few times in my life I found myself in the situation of using it, and with success!), but most importantly, please base your decision on actually experience-verified facts, and not on things you've heard others say, or that perhaps you experienced a long time ago.