Share Tweet Share





First of all, I’d like to apologize to Rob Wulsch and the MySQL community for not working with Rob in advance of his talk at West, “The Elephant in the Room“. I’ve seen Rob around so many conferences and PostgreSQL events that I assumed that he had done this kind of talk before. In retrospect, I should have spent the afternoon before working with him on his slides and themes, or talked JD into making his talk a regular session. I also plead illness: I contracted a lung infection at West which I am not yet completely over. So, excuses out of the way, I’ll address some of Rob’s major points for my PostgreSQL readers because I don’t feel that they were really understood. Our community tends to focus on technical details to the exclusion of more big picture issues, and Rob’s talk wasn’t primarily about technical issues. Since I happened to be sitting at the table with Mark Callagahan and some other MySQL geeks during this session, and got an earful.

Respecting MySQL

“MySQL is not a toy” was Rob’s main point, not “VACUUM sucks”. Many members of the PostgreSQL community express contempt for MySQL and bash it as “not a real database”. Regardless of what you, personally, think of MySQL’s design choices, clearly they are design choices which resonate with a large number of people an with quite a few multi-million-dollar businesses. For Postgres community members to dismiss MySQL out of hand means remaining ignorant of what a very large market wants out of their database system … and means that Postgres will never penetrate that market. We also make ourselves look pretty silly when we say that one of the most lucrative internet businesses in history is based on a “toy”. Besides, saying to someone who has based the last 6 years of their career on becoming a MySQL expert “it’s a toy” is inexcusably rude, and not likely to get them interested in trying Postgres. Especially on the PostgreSQL IRC channel, I’ve witnessed moments of breathtaking rudeness towards MySQL and developers. It’s time that certain members of our community at least learned how to be polite. Maybe we need a finishing school.

Outdated FUD

“Don’t talk to me about MyISAM.” Rob also pointed out that the PostgreSQL community is as guilty as the MySQL community in using outdated configurations and versions for comparison. For example, it’s very common for PostgreSQL advocates to attack the lack of data integrity inherent in MyISAM, even though almost nobody intentionally uses MyISAM in production today. “MySQL doesn’t have” statements regarding features which MySQL added in 5 or 5.1 are also all-too-common. Such inaccurate statements are the bane of effective advocacy. Once your audience realizes that you’ve made an inaccurate statement about MySQL, they’ll tend to assume that everything coming out of your mouth is BS — and rightly so. For that matter, doesn’t it drive you batty when MySQL or NoSQL geeks make statements about PostgreSQL based on the performance and functionality of version 7.2? Don’t do the same.

Fast Startup, Long Maintenance

“It just works … with issues.” This was a repeated refrain from Rob, and not really pointed up as a theme. However, it’s a very important idea and one which we need to understand in Postgres-land. MySQL, like Microsoft, has successfully exploited the idea of “start fast, troubleshoot later” which appeals to vast numbers of beginner and casual DBAs. Postgres tends to make startup time very high, but once your system is configured you never have to touch it. MySQL makes startup time very low, but requires admins to spend years devising workarounds for minor bugs and feature limitations. This makes MySQL sound very unattractive, but it’s a question of unattractive to whom. Today, the average DBA is not a trained professional but rather a developer or sysadmin who was pressed into DBA duties and whose primary job requirement is to get things running fast. Bugs can be “dealt with later”. And for that matter, from the perspective of the “casual DBA”, there is no difference between actual database bugs and problems caused by not having time for the study required to configure or manage the system. To them, PostgreSQL and MySQL (or for that matter, MongoDB) are equally buggy. This lesson is something which I’ve noticed many folks on pgsql-hackers still don’t understand. I’ve met resistance in attempts to simplify replication which amount to “if the users aren’t smart enough, we don’t want them using Postgres”. This is a very short-sighted attitude and will lose us our user base. Continued tomorrow …