[Discuss] Rob Conery's critique of MySQL?

[Greg Rundlett (freephile)]

In my career, I've focused mostly on open source "solutions" like
Drupal for CMS, MediaWiki for Knowledge Management, RT for helpdesk
ticketing, KnowledgeTree for document management, SugarCRM for CRM.
These open source projects are very popular, and for the most part
they use MySQL as the default db backend.  This makes using these
products with PostgreSQL more risky (b/c less tested) and may even
require a lot of work because contributions (aka modules or
extensions) are based on MySQL and may contain non-standard SQL.
MySQL is hugely popular because of the history of open source.  It is
used in many high-profile and enterprise (Yahoo!) environments.
MySQL, and variants like MariaDB (http://mariadb.org/), have a healthy
and ever-improving ecosystem.  There are far more people with MySQL
experience -- be that beginner or expert -- than PostgreSQL
experience.  For these reasons, MySQL will continue to be both
mainstream, and a viable choice as a database system.

That said, I believe that awareness, and the desire to use PostgreSQL
is expanding, as database technology in general has become more of a
central topic these days due to the whole SQLite, NoSQL, JSON, Big
Data movements.  This awareness is happening at both the developer
level, and the business level.

Meanwhile, a lot of people continue to fall into the same traps, or
are limited by "conventional wisdom".  A lot of books, forums,
outright projects (PEAR DB, ADODB, Zend Framework, etc.) or what might
be best termed "conventional wisdom" promote the idea of using a
database abstraction layer to make the DB choice "irrelevant" or
easily switched.  This is a fallacy.  Jeremy Zawodny posted on it in
2004 at http://jeremy.zawodny.com/blog/archives/002194.html  I like
his quote: That's no different from saying "I'm going to limit myself
to the subset of PHP that's the same in Perl and C, because I might
want to switch languages one day and 'painlessly' port my code."  Once
you dig into and understand the features of a database product, and
you understand the database needs of a software project, and you take
into account your (company's) available expertise and tooling; you
invariably design the application to make use of a particular database
system.  An "abstraction layer" is something which codifies how a
developer should have his code talk to the database in that
application (so the application can take care of things like
clustering, table prefixing etc).  MediaWiki software is one that uses
it's own internal database abstraction layer to create a standardized
way for the application code to interact with the database... but
again it's not a means to swap the database.  [1] [2]  The libraries
like ADODB *do* serve a very useful purpose: They allow a software
project to maximize it's install base into existing technology
infrastructures.  They don't make the choice of db irrelevant.

A case study in success: Wikipedia
Wikipedia is one of the top ten websites in the world, currently
getting about 400 million unique visitors a month. It gets over
100,000 hits per second. [3]
Wikipedia uses MySQL and it serves them well.  The software
(MediaWiki) has PostgreSQL (and Oracle) support for wider deployment
http://www.mediawiki.org/wiki/Manual:Installing_MediaWiki#Postgres and
it's own internal, centralized database layer.

If you are interested in migrating production applications to
Postgres, one more (large) vendor who can help is Bull HN Information
Systems.  Bull has a website called postgresmigrations that's worth a
look and in particular there is this recent discussion about why
Postgres is not more widely deployed
http://www.postgresmigrations.com/blog/post/3323648/index.html
(Disclaimer: Bull's web presence is horrible)

[1] http://www.mediawiki.org/wiki/Manual:Database_access
[2] http://svn.wikimedia.org/doc/GlobalFunctions_8php.html#a44dcb6be36dfa8f9278fa98c066c82f4
[3] http://www.mediawiki.org/wiki/Manual:MediaWiki_architecture