If they had to rewrite ORACLE they would probably end up with PostgreSQL

‍

Oh yes. I know this is bold, but coming from an ORACLE and PostgreSQL DBA with over 20 years of experience, please bear with me.

ORACLE is the best RDBMS around but it comes with a cost, and I am not talking about the skyrocketing purchase and support costs.

This post (and hopefully the next ones, If I don't get tired by then) is about the other hidden costs. For example ease of development and maintenance.

Today I will set the focus on the numerous ORACLE parameters related to managing a standby database compared to PostgreSQL.

‍

A short background first.

‍

Oracle delivers a great physical standby option. A physical standby is a copy of the production aimed primarily to serve as a DR (disaster recovery) site. Once your production database goes down for any reason, the standby kicks in and becomes the primary database. This is until the original primary is recovered.

Newer oracle versions enable querying the standby copy, releasing the production database from many heavy reports.

‍

The ORACLE standby solution is everything a DBA hope for. It is a fast,extremely stable and well tested solution that will not fail you, provided is was deployed and maintained properly.

PostgreSQL also delivers a standby database. It has roughly the same features (Yes, It supports a hot standby where you can query the standby) and it is also absolutely free.

I believe PostgreSQL's standby is also easier to deploy and maintain. Being easier to deploy and maintain makes the PostgreSQL physical standby as stable as the ORACLE standby as it is less prone to misconfiguration.

‍

In the next part, we’ll delve deeper into the specifics of ORACLE and PostgreSQL standby setups.

‍

Cluster Spotlight

‍

Your go-to source for all things 123cluster: platform news, step-by-step tutorials, and can’t-miss community events. Whether you’re spinning up a new cluster or fine-tuning an existing one, these resources will empower your workflow and spark new ideas.