Re: Oracle DBA to PostgreSQL DBA?

  • From: Igor Racic <igor.racic@xxxxxxxxx>
  • To: thomas.kellerer@xxxxxxxxxx, "oracle-l@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>
  • Date: Fri, 23 Dec 2016 14:44:20 +0100

Hi Thomas,

Thank you for this interesting summary.
From dev side, one surprising point, you have to terminate transaction when
some error occurs. Can't continue with DML, just commit or rollback. (do
not remember if it was JDBC only)

Any interesting experience with support provider(s) ?
Anyone tried to look in code & contibute something ?

Regards,
Igor



2016-12-19 9:13 GMT+01:00 Thomas Kellerer <thomas.kellerer@xxxxxxxxxx>:

I have been an Oracle DBA now for 20+ years and am maybe a little set
in my ways. It is possible that at the company that I work at we
might convert from Oracle to PostGreSQL in the future to save on
licensing costs.

First: _if_ you want to be a Postgres DBA, spell the name correctly ;)
It's either Postgres or PostgreSQL (no capital G)

Feature rich enough to be a good choice for a small company enterprise
database?

I am not a DBA - I am a developer with a strong focus on relational
databases.

So I can't judge on the "DBA career choice" of your question.
But I would like to answer on the "feature rich enough" question.

We have migrated several mid-sized database projects from Oracle to
Postgres and never looked back.

Postgres is in a lot of areas on-par with Oracle, and in a lot of areas
ahead of Oracle especially on the SQL/programming level. Oracle still has
no transactional DDL (which is a killer feature when testing deployments).
Postgres has a much more feature rich set of data types (boolean, a REAL
date, time, range types), exclusion constraints, writeable CTEs and a
*much* better String/Varchar handling (the new 32k limit in 12c just
doesn't cut it - it's horribly slow and we went back to CLOBs which are
still slow but faster then a 32k VARCHAR)

Postgres on the other side has no support for PL/SQL packages, parallel
DML, parallel query (9.6 has some limited parallel query capabilities),
column store, an in-memory option and probably some more EE features that I
am not aware of.

I think the biggest gap is in the monitoring and manageability area.
Things like zero-down time upgrades (through a hot-standby), AWR, ASH,
exposure of wait events, all those nice V$ views, proper partitioning or
SQL profiles are still missing.

Postgres has no query hints (and some people claim that that Postgres is a
toy database just because of that). But in those cases where the query can
be changed, re-structuring of the query usually is a much better choice
anyway. In 25 years of a database developer I can probably count the number
of times I was forced to use hints on my two hand.

I do agree however that the absence of SQL profiles is a problem for those
applications where the SQL can't be changed (but as that is not the line of
business I am in, it's typically not a problem in our environment where we
usually roll out a new version of the application to fix database
performance problems)

The development pace in the Postgres community is also very fast and I
assume that it will close the gaps faster then Oracle would like it (proper
partitioning seems to be coming next year for example, and rolling upgrades
aren't that far away either).

Thomas

--
//www.freelists.org/webpage/oracle-l



Other related posts: