Re: young guy wanting (Postgres DBA) ammo - Mailing list pgsql-general

From Tom Lane
Subject Re: young guy wanting (Postgres DBA) ammo
Date
Msg-id 22209.1193981183@sss.pgh.pa.us
Whole thread Raw
In response to Re: young guy wanting (Postgres DBA) ammo  (Kevin Hunter <hunteke@earlham.edu>)
Responses Re: young guy wanting (Postgres DBA) ammo  (Andrew Sullivan <ajs@crankycanuck.ca>)
List pgsql-general
Kevin Hunter <hunteke@earlham.edu> writes:
> At 12:35a -0400 on 02 Nov 2007, Tom Lane wrote:
>> He's full of it ... mysql is not any easier to run or tune.

> I expected as much, but would you give me something more than "Because
> Tom says so!"  Good enough for me, but not for a
> non-Postgres-indoctrinated person, I fear.  ;-)

Well, let's see:

* Installation: on practically any platform that "I don't want to be a
DBA" people would use, it's a wash.  You download a package, you do
the local equivalent of "sudo service <foo> start", and there you
are.  I'm only really familiar personally with the details of this for
Red Hat systems, but being personally responsible for RH's packaging of
both postgres and mysql, I can tell you they are isomorphic.

* Initial configuration: well, both DBs are a bit unfriendly when it
comes to setting up some initial database users and configuring a
sane security policy.  This is actually a hard problem since "sane"
means different things to different people, so a one-size-fits-all
preconfigured solution doesn't work.  IMHO, for both DBs you're
in for some manual-reading whether you like it or not.  Red Hat's
packages of the two are not isomorphic on this point --- RH forces ident
authorization by default for PG, while mysql is left with its default
behavior which is comparable to PG's "trust".  (Don't ask me why, those
decisions were made before I got here.)  We see the blow-back from the
forced ident authorization on our lists, in that people can't figure
out how to get into the DB initially, and I'm sure there are people
out there who don't get past that hurdle and just give up.  It would
be interesting to troll the mysql lists for evidence of the downside
of their default ... which'd be along the line of "someone broke into
my completely insecure database and stole/destroyed all my data" ...

* Tuning: there used to be some truth to the "PG is hard" meme here,
in that the out-of-the-box defaults for PG were designed for what we'd
now consider laughably small boxes.  PG is now cranked up to the point
of being sanely configured for merely small boxes, which is about where
the out-of-the-box mysql configuration is too.  If you want you can
award mysql a few points for providing sample config files for larger
configurations, but even knowing that one of those should be installed
is knowledge that an "I don't want to be a DBA" person wouldn't have.
I think that in either case you're going to end up fooling with the
configuration parameters if you're doing anything much more demanding
than cataloging your baseball cards.

* Routine backups: seems about the same to me; in both cases you
gotta do something along the lines of setting up a cron job to call
a DB-supplied program.

* Replication: I'll grant that mysql has got built-in replication that
is easier to set up than any PG alternative I know about.  But is the
"I don't want to be a DBA" crowd planning to run replication, or likely
to get it right without reading any manuals?

Certainly there is a perception out there that mysql is easier,
but I think it's based on out-of-date information.  You might also
care to read Greg Smith's take on the matter:
http://www.postgresql.org/docs/techdocs.83.html
He points out that each DB's developer community has been working
over the past few years to ameliorate their respective perceived
disadvantages ...

            regards, tom lane

pgsql-general by date:

Previous
From: Kevin Hunter
Date:
Subject: Re: young guy wanting (Postgres DBA) ammo
Next
From: Lew
Date:
Subject: Re: young guy wanting (Postgres DBA) ammo