Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
Lists: pgsql-adminpgsql-advocacypgsql-generalpgsql-novicepgsql-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

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")
"We are all somehow dreadfully cracked about the head, and sadly need
mending." --/Moby-Dick/, Ch 17 

In response to


pgsql-novice by date

Next:From: JoshDate: 2007-06-19 16:03:46
Subject: Re: [PERFORM] Postgres VS Oracle
Previous:From: Joshua_KramerDate: 2007-06-19 14:54:06
Subject: Re: [pgsql-advocacy] [PERFORM] Postgres VS Oracle

pgsql-performance by date

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

pgsql-admin by date

Next:From: Tom LaneDate: 2007-06-19 16:00:43
Subject: Re: Export/import issue/question
Previous:From: Karl WrightDate: 2007-06-19 15:18:42
Subject: Export/import issue/question

pgsql-advocacy by date

Next:From: JoshDate: 2007-06-19 16:03:46
Subject: Re: [PERFORM] Postgres VS Oracle
Previous:From: Joshua_KramerDate: 2007-06-19 14:54:06
Subject: Re: [pgsql-advocacy] [PERFORM] Postgres VS Oracle

pgsql-general by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group