On Wed, Dec 16, 2009 at 2:44 PM, Greg Smith <greg@2ndquadrant.com> wrote:
> 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.
The important point here is that the bug was introduced to a stable
branch, fixed halfway, then detected again, then fixed yet again.
This does not instil confidence in their QA or code review.
As a for instance of who runs PostgreSQL and who runs MySQL, we have
slashdot and the .info and .org TLDs. When you go to slashdot.org and
it's not working right, that's MySQL acting up. When you can't get to
any .info or .org domains, that's PostgreSQL.
I've had slashdot have a non-functioning database underneath it quite
a few times (note that the site stays up, but you can't edit anything
because it's all static). I've never once had the .org or .info TLDs
go down on me.
