Tom Lane wrote:
> Kevin Hunter <hunteke@earlham.edu> writes:
>
>> However, I'm not a DBA and only minimally know what's involved in doing
>> the job, so I don't have "ammo" to defend (or agree?) with my friend
>> when he says that "Postgres requires a DBA and MySQL doesn't so that's
>> why they choose the latter.
>>
>
> He's full of it ... mysql is not any easier to run or tune.
>
Kevin,
If you work at an edu and want to talk to our DBA team at a large edu
around operational DBA issues with MySQL, Postgres, Oracle and SQL
Server, feel free to contact me off-list.
My long-winded version of Tom's succinctness:
Our shop supports all four. I am not a fanboi of any. Postgres
continues to impress our shop with how reliable the core engine is, and
how concerned with documented behavior and how concerned with following
standards the project is.
I don't want to just rip on MySQL, as there are some things it does do
well, but the perceived "it's so easy" is a total illusion. I
personally have gone on rescue missions to various departments around
our University to rescue data (sometimes very important research data,
upon which future grants depend) from the clutches of a dead or dying
MySQL installations that were "just set up so easily" some time
before. Projects where no one knows the database engine where their
data is stored always end badly.
The commercial database platforms and mysql continue to pitch how easy
their engine is, how it tunes itself, etc, in order to compete in the
marketing arena of the perception of total cost of ownership. Less DBA
time is cheaper, goes the thinking, and so the smart manager avoids
strategic decisions that carry larger fixed overhead costs. It makes
for colorful glossy brochures.
It does not really match reality, though, because how well and how many
projects a team of X DBAs can support is more a function of how far the
projects push the envelop with the database engine. And this pushing
can happen in a lot of directions: what tools are being used, how large
are the datasets, how demanding are the uptime requirements and
performance requirements, how many features of the engine does the
project exploit, how are releases done, etc etc. This stuff never
factors into the marketing hype, but this is where it gets real.
If your shop must meet any formal audit standards, you will be
hard-pressed to do this without a DBA. If you *are* able to meet audit,
then some other group(s) must be doing this work. A rose by another
other name costs just as much.
There are other reasons that make sense for a shop to decide what RDBMS
is best for them, but the alleged reason of "MySQL requires less time"
is definitely not one of them.
HTH,
Paul
