[Discuss] Rob Conery's critique of MySQL?

[Rich Braun]

Mark Woodward <markw at mohawksoft.com> observed:
> My favorite example is facebook. Yes, they are a big data show case.
> OMFG they have a lot of data and a lot of computational requirements.
> They did not start out dreaming of big data. It started small and grew.
> I believe that this inadvertent strategy helped them greatly. By
> focusing on the site and what it did and *not* how to make it scale
> until scalability was needed they were able to be attractive to more
> users more quickly.
>
> Opinions?

Being the one who kicked off this thread, my original goal was to get specific
technical arguments (plus a couple of business arguments like the ratio of
MySQL-experienced DBAs to PostgreSQL DBAs available on the job market) to
present to decision-makers who control what technology to use on new projects.

So far at work I've got MyWay or the HiWay from the bosses: thou shalt use
MySQL.  Period.  Suits me OK because I already know its quirks well, but it
looks to me like more than ever the alternative of PostgreSQL (and no other
FOSS product) is viable for small and large companies alike.

But the thrashing of this discussion thread has given me nothing to send off
to the senior tech architects at my office.  Not one of the postings here has
been phrased in a way that would grab such a person by the throat and persuade
them to read further.

Your argument above, Mark, is what I hear all the time both here and at my
last employer:  "We're Agile, so we can start off doing things wrong and fix
them later."  About $15 million and 20 months into a $6 million/9-month
project (hah), at my last job we recognized that what the software team had
built was a bug-ridden replacement of the previous unsupportable bug-ridden
software, and most of the new software's developers quit--leaving the
replacement equally unsupportable.  But hey, the new one had lots of fancy
stored-procs and took advantage of all of MySQL 5.1's nifty features.

So if it were /my/ $15 million, I'm not so sure I'd take the position that I
should focus mainly on the software features.  But of course, I'm an infra guy
so I'm biased:  the infra goes in (2 of everying, HA from the get-go) before
the first feature gets crafted.  It's cheap enough to do these days, though it
hasn't gotten much easier.  If PostgreSQL makes it easier to set up HA, and
recover from failures, than MySQL--I'd love to make that case.  But going back
to the Facebook startup argument--let's build this cool web page and see if
people like it--then the HA argument doesn't even get considered.

Another example is firewall security:  if you've got this cool new web site
running, and later decide to add firewalls:  it'll be a lot more effort, and
probably more outage-prone, trying to figure out on the fly which TCP ports
and IP addresses should be opened up, and how to pull apart portions of the
app to run on back-end servers with layered security.

So, that's why I like to include robustness as part of Iteration Zero in the
agile framework.

-rich