This is the final episode of this short series of blog posts on some of my drivers for moving to Postgres from Oracle.
Please do read Part I and Part II of the series if you have not done so. It discussed the topics “History”, “More recently”, “The switch to Postgres”, “Realization”, “Pricing”, “Support” and “Extensibility”.
In summary:
- Part one focused on “why not Oracle anymore, so much”
- Part two discussed the comparison between PostgreSQL and Oracle
- Part three talks some more about what Postgres then actually is
Community
One of the more important things to be really, really aware of is that Postgres is “not just open source“. Postgres is “community open source“.
Now, why would that be important, you might wonder.
We all know what open source stands for. There are many advantages to an open source system, and in our case, an open open source database.
A number of arguments are in this blog post series. If you take this one step further though and realize that Postgres is a community open source project, what are the extra advantages?
A community open source project is not limited, in any way, to any one specific group of developers (let’s call them a company). For example, let’s look at MongoDB. This is an open source database, but it is developed by MongoDB Inc. It is, in essence, controlled by MongoDB.
Postgres is developed by the Postgres Developer Community coached by the Postgres Core Team.
This makes Postgres incredibly open, independent and it enables its developers to truly focus on actual business problems that need to be solved. There is no ulterior drive to satisfy commercial goals or meet any nonessential requirements.
Development
A very important discriminator, that only became this clearly and apparent to me, after I dove into Postgres some more, is the development…
The actual development of the database core software is done by this community, we’ve just identified.
“Well, yes…” you might say, this is what open source stands for. But the impact of this extends well beyond support, as I mentioned in part 2 of this series. The ability to be part of where Postgres goes, to have actual influence on the development, is awesome, especially for a database platform in the current “world in flux”. Postgres users don’t necessarily have to wait until “some company” decides to put something on the road map or develop it at their discretion. These company decisions will mostly be driven by the most viable commercial opportunity, not necessarily the most urgent technical need.
The development of Postgres is more focused on “getting it right”.
One nice example is the Postgres query optimizer. The Postgres community hates bugs. When bugs start to get discussed, it results in many emails within the community, which stand for a lot of reading! Many bugs are fixed very quickly so that this email storm stops!
For optimizer bugs, therefore, turnaround times (from reporting to having a production fix) can be as low as 72 hours, even for mechanisms as complex as a query optimizer.
Invitation
I would like to invite all of you in the Oracle community to take a look at the Postgres query optimizer and share your concerns, worries, bugs, or praise with the Postgres community. If you want to, you can share this with us at the https://www.postgresql.org/list/pgsql-hackers/ email list. We are looking forward to your contributions!
Future
Oracle
I can only speak from what I see. What I see is that Oracle is becoming an online services company. I see them moving away from core technology like the database and accompanying functions. Oracle is more and more and moving to highly specialized applications aimed at very big companies.
Chatbots, social media interactions, integrated services, and more, delivered from a tightly integrated but also tightly locked set of Oracle-owned and -operated data centers, or rather, the Oracle cloud.
Is this useful? Of course, there will be targeted customers of Oracle who will continue to find this all extremely useful, and it will be, to them.
It this for me? No, not really.
PostgreSQL
In the beginning, Linux was not something anyone wanted for anything serious. I mean, who wanted to run anything mission critical on anything else than Solaris, HP-UX, VMS, IBM? No one…
And that was just a few years ago. Imagine!
Today in any old data center, if you would eliminate the Linux-based servers, you would not have much left.
This same thing is now also happening in what I guess is the second wave of open source. More complex engines are being replaced by open source and the ever-present relational database engine is one of those.
Why? Price, extensibility, flexibility, focus, you name it. We have seen it before and we will see it again.
EnterpriseDB
If you permit me just these few words.
I think EnterpriseDB is extremely important for PostgreSQL. We have been fighting on the forefront since the beginning, supporting PostgreSQL’s move to the Enterprise. EnterpriseDB has been and will continue to spend a large amount of our resources to PostgreSQL. We are a PostgreSQL support company. We just have been not very good at patting ourselves on the back…
As a company, we are doing extremely well, simply because Postgres is rock solid in all facets and ready to take on the word, even the most daunting tasks – and beyond.
This will continue as Postgres will continue in this second wave of Open Source.
I thank you for your attention.
If you have additional questions or comments, please do not hesitate to contact me.
(Article originally published on author's private blog - Monday, January 27, 2018, @http://www.jk-consult.nl/why-i-picked-postgres-over-oracle-part-iii/)