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

Re: [pgsql-advocacy] [PERFORM] Postgres VS Oracle

From: Chris Browne <cbbrowne(at)acm(dot)org>
To: pgsql-admin(at)postgresql(dot)org
Subject: Re: [pgsql-advocacy] [PERFORM] Postgres VS Oracle
Date: 2007-06-19 13:49:45
Message-ID: 60lkegdpfq.fsf@dba2.int.libertyrms.com (view raw or flat)
Thread:
Lists: pgsql-adminpgsql-advocacypgsql-generalpgsql-novicepgsql-performance
achill(at)matrix(dot)gatewaynet(dot)com (Achilleas Mantzios) writes:
>> I don't want to add gas to the flamewar, but I gotta ask.  What is in
>> the the 90 to 95% referred to in this email.
>
> short answer: all cases, possibly except when running a Bank or something 
> similar.

No, it's not to do with what enterprise you're running; the question
is what functionality is missing.

At the simplest level, I'd say that there are Oracle (+DB2) feature
sets that *are compelling*, particularly in the High Availability
area.

However, those feature sets are ones that require spending a Big Pile
Of Money (BPOM) to enable them.  

For instance, ORAC (multimaster replication) requires buying a bunch
of servers and spending a BPOM configuring and administering them.

If you haven't got the BPOM, or your application isn't so "mission
critical" as to justify budgeting a BPOM, then, simply put, you won't
be using ORAC functionality, and that discards one of the major
justifications for buying Oracle.

*NO* small business has that BPOM to spend on this, so *NO* database
operated by a small business can possibly justify "buying Oracle
because of ORAC."

There will be a lot of "departmental" sorts of applications that:

- Aren't that mission critical

- Don't have data models so sophisticated as to require the "features
  at the edges" of the big name commercial DBMSes (e.g. - partitioning,
  OLAP/Windowing features) that PostgreSQL currently lacks
   
and those two categorizations, it seems to me, likely define a
frontier that allow a whole lot of databases to fall into the "don't
need the Expensive Guys" region.
-- 
"cbbrowne","@","cbbrowne.com"
http://www3.sympatico.ca/cbbrowne/oses.html
Rules of the Evil Overlord #219. "I will be selective in the hiring of
assassins.   Anyone who  attempts to  strike down  the hero  the first
instant his back is turned will not even be considered for the job."
<http://www.eviloverlord.com/>

In response to

pgsql-novice by date

Next:From: Robert TreatDate: 2007-06-19 14:41:29
Subject: Re: [GENERAL] [PERFORM] [ADMIN] Postgres VS Oracle
Previous:From: Chris BrowneDate: 2007-06-19 13:39:02
Subject: Re: [pgsql-advocacy] [PERFORM] Postgres VS Oracle

pgsql-performance by date

Next:From: Mark LewisDate: 2007-06-19 13:50:30
Subject: Re: Performance query about large tables, lots ofconcurrent access
Previous:From: Alvaro HerreraDate: 2007-06-19 13:46:37
Subject: Re: Performance query about large tables, lots of concurrent access

pgsql-admin by date

Next:From: Kevin GrittnerDate: 2007-06-19 14:10:47
Subject: Re: Explained by known hardware failures, or keeplooking?
Previous:From: Chris BrowneDate: 2007-06-19 13:39:02
Subject: Re: [pgsql-advocacy] [PERFORM] Postgres VS Oracle

pgsql-advocacy by date

Next:From: Robert TreatDate: 2007-06-19 14:41:29
Subject: Re: [GENERAL] [PERFORM] [ADMIN] Postgres VS Oracle
Previous:From: Chris BrowneDate: 2007-06-19 13:39:02
Subject: Re: [pgsql-advocacy] [PERFORM] Postgres VS Oracle

pgsql-general by date

Next:From: Rikard PavelicDate: 2007-06-19 13:51:51
Subject: problems selecting from altered table
Previous:From: Merlin MoncureDate: 2007-06-19 13:40:16
Subject: Re: Subquery problems

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