Re: Oracle DBA to PostgreSQL DBA?

From: Thomas Kellerer <thomas.kellerer_at_mgm-tp.com>
Date: Mon, 19 Dec 2016 09:13:25 +0100
Message-ID: <cdeba8b4-3240-625d-4f5b-950658ac491f_at_mgm-tp.com>


> 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

--
http://www.freelists.org/webpage/oracle-l
Received on Mon Dec 19 2016 - 09:13:25 CET

Original text of this message