[Discuss] Rob Conery's critique of MySQL?

[markw at mohawksoft.com (Mark Woodward)]

On 08/04/2012 01:50 PM, Rich Braun wrote:
> 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.

OK, yea, we got caught up the No-SQL vs SQL argument.
>
> 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.

I have to say something that I don't like saying because I sound like a 
jerk. Sometimes, if you need to ask a certain type of question, then 
answer can't do you any good.

Seriously, in the MySQL vs PostgreSQL debate, if you know about database 
theory and have some serious experience with databases other than MySQL, 
you would say there is no debate, PostgreSQL is the obvious choice. If 
you don't have the background or experience, then, things like MVCC, 
ACID, and transactions don't mean anything to you. Worse yet, chances 
are you'll see them as a problem because in a single stand-alone query, 
they do add additional processing.

Compare it to the "squared circle" debate in math. If you don't 
understand PI, you won't accept it.

>
> 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.
Well, it is almost assuredly impossible to start at position 0 and get 
it right the first try. There is "institutional learning" involved. This 
is where the development team is learning about what they are creating 
as a business. This is typically the start up phase of a company or a 
new product.  By the time you get system up and running, the design has 
almost certainly churned over several phases.

Site 2.0 is typically sold internally as the "rebuild to end all 
rebuilds." It never is. It is defined as the fix to all the mistakes 
that were made for all those many reasons during 1.0.

I wish I could give you some real ammunition, but it isn't about 
bullets, it is about really knowing the subject matter. Anyone wanting 
to defend their position will have bullets too. You need to know WHY 
your bullets are better, and more importantly, you need to know why 
their bullets are wrong.

I could rattle off a number of pros and cons for PostgreSQL, but it 
would not help. Real knowledge is the only way to win this debate, if, 
of course, it can be win. Some people's minds can not be changed no 
matter what proof is given. I have had to make this argument before, and 
failed because a director or CTO is "confident" that MySQL can do it 
regardless of proof to the contrary. The result, the project either 
fails or needs a lot of extra work. Its painful, but it happens all the 
time in industry.

The only advice I can give you is this: learn why PostgreSQL is 
absolutely better than MySQL, merely quoting someone else's opinion 
won't help you. The subject of databases has some REAL computer science 
and if you love the science, you'll love good databases because they 
have it all. It may not help you in this particular situation, but it 
will certainly make you better at what ever job you do.