Re: Oracle vs. PostgreSQL - a comment

From: Paul Förster <paul(dot)foerster(at)gmail(dot)com>
To: Tim Cross <theophilusx(at)gmail(dot)com>
Cc: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Oracle vs. PostgreSQL - a comment
Date: 2020-05-31 06:20:33
Message-ID: 24F7752C-AA89-4EC8-B142-DAD6F6E92048@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi Tim,

> On 30. May, 2020, at 23:14, Tim Cross <theophilusx(at)gmail(dot)com> wrote:
> I didn't encounter the bugs you seem to have unless I wondered off into their 'add-ons'.

use Oracle Text for example and you'll sooner or later run into severe bugs. My current favorite is ORA-20084 which bugs me for almost a year now. Text index corruption is really painful and Oracle does not feel inclined to fix it.

> Sticking with the base RDBMS, I found it to be pretty solid and reliable.

yes, but who does that? We have loads of third party applications which do all the stuff we (DBAs) don't want them to do.

> The oracle installation process is horrible.

that's why I scripted the whole create database thing, including PDBs, and their parameters, file paths, etc. For example, my script to create a container database is 782 lines long, whereas PostgreSQL just needs an "initdb". And my script to create a PDB still has 277 lines whereas in PostgreSQL, you can do it with a simple "create database" line.

Even moving a database to another path is a nightmare as you'd have to create new controlfiles, etc. With PostgreSQL you just change the PGDATA variable after moving/copying the whole database cluster and that's it. Well, if you copy it and want to run both at the same time, you still have to change the port in postgresql.conf of course.

Installing database software and creating a database is pretty easy compared to other Oracle stuff. Did you ever install an Oracle Enterprise Manager or Oracle Universal Directory? Don't! That's when the pain really starts.

> Worse still, some of those bugs have been there for 20 years and are just
> 'known' issues experienced DBAs deal with. Their documentation site is
> also horrible.

sic! :-)

> The way they handle indexes and updates is also much faster than postgres and you have to worry less about the structure of your queries with respect to performance.

and then, some day, a developer approaches a DBA with a query which is generated and, if printed out in a 11pt. sized font, can fill a billboard on a street, to optimize it or search for what's wrong with it, or why it performs so slow... That's usually when I play BOFH because I'm not willing to debug 10 pages which its creator hasn't even cared to take a look at first. :-P :-)

Same goes for the app guys sending me 10 MB of Java stack trace by email containing one single line of ORA-xxxxx. They should send only that line along with a (approximate) time when it occurred. If I get the full stack trace, I send it back to them telling them they should come back when they find the line containing the ORA message. They usually don't come back because they don't know how to grep. :-) Some do, though, and those are the ones I try to help.

> If I'm in an environment where someone else is responsible for all the DBA stuff, Oracle is nice to work with.

yes, leave the cardiac arrest to us DBAs. :-P

> apart from this, Oracle licensing is an absolute nightmare. Apart from
> the expense, the complexity is unbelievable and it is almost impossible
> to know with any certainty what you will be paying in 12, 24 or more
> months.

that's why we are migrating more and more to PostgreSQL and why I came in touch with PostgreSQL at all. There will be some applications which are bound to Oracle and which we never get rid of but we move as many applications to PostgreSQL as is possible to reduce license costs. And it already has payed out!

Cheers,
Paul

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Hans 2020-05-31 13:19:42 Trigger not firing
Previous Message Igor Polishchuk 2020-05-31 04:33:36 Postgresql 9.6 -> AWS RDS Postgresql 12.2 with pg_logical