Re: [PERFORM] Postgres VS Oracle

From: Chris Browne <cbbrowne(at)acm(dot)org>
To: pgsql-advocacy(at)postgresql(dot)org
Subject: Re: [PERFORM] Postgres VS Oracle
Date: 2007-06-19 15:22:17
Message-ID: 603b0odl5i.fsf@dba2.int.libertyrms.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-advocacy pgsql-general pgsql-novice pgsql-performance

josh(at)globalherald(dot)net (Joshua_Kramer) writes:
>> The most important point is that third one, I think:
>> "any application where reliability requirements do not warrant
>> spending $1M to make it more reliable"
>>
>> Adopting ORAC and/or other HA technologies makes it necessary to
>> spend a Big Pile Of Money, on hardware and the humans to administer
>> it.
>
> If I were CIO that did not follow the Postgres groups regularly, I
> would take that to mean that Oracle is automatically more reliable
> than PG because you can spend a BPOM to make it so.

That would be incorrect.

In cases where you *do not* spend the BPOM, there is not any
particular evidence available to indicate that Oracle is, in any
interesting way, more reliable than PostgreSQL.

How many CIOs check into the PostgreSQL advocacy group, just to pick
out one article?

> Let's ask a different question. If you take BPOM / 2, and instead of
> buying Oracle, hire consultants to work on a PG solution, could the PG
> solution achieve the same reliability as Oracle? Would it take the
> same amount of time? Or heck, spend the full BPOM on hardening PG
> against failure - could PG achieve that reliability?
>
> Or, by spending BPOM for Oracle strictly to get that reliability, are
> you only buying "enterpriseyness" (i.e. someone to blame and the
> ability to one-up a buddy at the golf course)?

The major difference, as far as I can see, is that if you spend BPOM
on Oracle, then you can take advantage of some High Availability
features for Oracle that haven't been implemented for PostgreSQL.

On the one hand...
- If you spend LESS THAN the BPOM, then you don't get anything.

On the other hand...
- If you spend SPOM (Some Pile Of Money ;-)) on hardening a PostgreSQL
instance, you may be able to get some improved reliability, but not in
the form of specific features (e.g. - ORAC) that 'smell like a
product.'

On the gripping hand...
- It is not entirely clear to what degree you can be certain to be
getting anything better than "enterpriseyness."

For instance, if your disk array blows up (or has a microcode bug
that makes it scribble randomly on disk), then that is liable to
destroy your database, irrespective of what other technologies are
in use as a result of spending the BPOM.

In other words, some risks are certain to be retained, and fancy
DBMS features can't necessarily mitigate them.
--
output = reverse("ofni.secnanifxunil" "@" "enworbbc")
http://www3.sympatico.ca/cbbrowne/wp.html
"We are all somehow dreadfully cracked about the head, and sadly need
mending." --/Moby-Dick/, Ch 17

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Tom Lane 2007-06-19 16:00:43 Re: Export/import issue/question
Previous Message Karl Wright 2007-06-19 15:18:42 Export/import issue/question

Browse pgsql-advocacy by date

  From Date Subject
Next Message Josh 2007-06-19 16:03:46 Re: [PERFORM] Postgres VS Oracle
Previous Message Joshua_Kramer 2007-06-19 14:54:06 Re: [pgsql-advocacy] [PERFORM] Postgres VS Oracle

Browse pgsql-general by date

  From Date Subject
Next Message Richard Huxton 2007-06-19 15:24:18 Re: problems selecting from altered table
Previous Message Gerhard Hintermayer 2007-06-19 15:20:25 Re: Apparent Wraparound?

Browse pgsql-novice by date

  From Date Subject
Next Message Josh 2007-06-19 16:03:46 Re: [PERFORM] Postgres VS Oracle
Previous Message Joshua_Kramer 2007-06-19 14:54:06 Re: [pgsql-advocacy] [PERFORM] Postgres VS Oracle

Browse pgsql-performance by date

  From Date Subject
Next Message Karl Wright 2007-06-19 15:28:23 Re: Performance query about large tables, lots of concurrent access
Previous Message Chris Browne 2007-06-19 15:11:19 Re: Maintenance question / DB size anomaly...