Search Postgresql Archives

Re: young guy wanting (Postgres DBA) ammo

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Tom Lane wrote:
Kevin Hunter <hunteke@xxxxxxxxxxx> 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







---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux