Re: Justifying a PG over MySQL approach to a project

You've probably already found
http://wiki.postgresql.org/wiki/Why_PostgreSQL_Instead_of_MySQL:_Comparing_Reliability_and_Speed_in_2007
which was my long treatment of this topic (and overdue for an update).

The main thing I intended to put into such an update when I get to it is
talking about the really deplorable bug handling situation for MySQL,
which is part of how all the data corruption issues show up. There's a
good overview of its general weirdness at
http://www.xaprb.com/blog/2007/08/12/what-would-make-me-buy-mysql-enterprise/
and the following series of pages lead you through my favorite set of bugs:

http://www.mysqlperformanceblog.com/2007/10/04/mysql-quality-of-old-and-new-features/
http://bugs.mysql.com/bug.php?id=28591
http://bugs.mysql.com/bug.php?id=31001
http://bugs.mysql.com/bug.php?id=37830

Basically, they made a performance optimization *in the stable release*
and fundamentally broke very basic behavior which didn't get caught by
their internal QA at all. That's a disaster that opens up serious
questions about both their project planning/structure and their QA too,
far as I'm concerned.

They do have a regression test suite:
http://dev.mysql.com/doc/refman/5.0/en/mysql-test-suite.html

But it's not really clear that they run it on every platform, i.e.
http://ourdelta.org/hidden-tests-of-the-mysql-testsuite

This supports the rumors I've heard that the development on the database
regularly cheats by just disabling tests that don't work right in some
situations, just so they can ship saying "there's no know issues!".
Obviously that's hearsay, but it sure seems to fit the facts we do know.

Meanwhile, PostgreSQL never does anything but bug fixes in their stable
version updates: http://www.postgresql.org/support/versioning

While the PostgreSQL regression testing build farm is completely public
and there is no tolerance for failed tests in the community:
http://buildfarm.postgresql.org/cgi-bin/show_status.pl

The main other reason why PostgreSQL has less corruption issues IMHO is
that there's exactly one "storage engine" and everybody works on it.
What the MySQL community calls options in storage engines I call split
QA, and the source of new types of failures not possible if you only
have one underlying storage codebase to worry about.

--
Greg Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.com