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
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.
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.
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!
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.
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.
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/)
... View more
Hi Jamie, You can also take a look here: http://jk-consult.nl/usergroup-conferences/ It's a selection of Postgres and Oracle conferences, ideal for cross-contiminating EnterpriseDB Postgres content at Oracle events, or just present for the community!!
... View more
Continuing this short series of blog posts on some of my drivers for moving to Postgres from Oracle.
Please read Part I of the series if you have not done so. It discussed the topics “History”, “More recently” and “The switch to Postgres”.
In the last months, discussing Postgres with my Oracle peers, playing with the software and the tooling, I actually quite quickly realized Postgres is a lot cooler, at least to me. Not so much of the overly complicated technology, but rather built to be super KISS. The elegance of simplicity and it still gets the job done.
Postgres handles a lot more complex workloads than many (outsiders) might think. Some pretty serious mission-critical workloads are handled by Postgres today. Well, basically, it has been doing this for many, many years. This obviously is very little known, because who would want to spend good money on marketing for Open Source Software, right? You just spent your time building the stuff, let somebody else take care of that. Well… we at EnterpriseDB do just those things, …too!
And, please, make no mistake, Postgres is everywhere , from your fridge and video camera, through TV set-top boxes up to major online banking software. Many other places you would not expect a database to (be able to) run. Postgres is installed in places that never get touched again. Because of the stability and the low to no-touch administrative character of Postgres, it is ideally suited for these specific implementations. Structured on some of the oldest design principles around Postgres, it doesn’t have to be easy to create the database engine, as long as it “just works” in the end.
Many years ago, an Oracle sales director also included such an overview in his pitch. All the places Oracle touches everybody’s lives, every day. This is no different for Postgres, it is just not pitched anywhere, by anyone, as much.
I have the fortunate opportunity to work closely together with (for instance) Bruce Momjian (PostgreSQL core team founding member ( and EnterpriseDB colleague). I also had the opportunity to learn from him some of the core principles on which Postgres was designed and built. This is fundamentally different from many other software projects I know and I feel it truly answers some of the core requirements of database projects out there today! There is no real overview of these principles, so that’s on my to-do list.
Working with PostgreSQL
Postgres is open source… it is true open source. It is even a true community open source project, but more about that later in the next installment.
Open source software is free to use, it does not cost nothing!
But, wait! Open source does not mean for free!? How…, why…, what do you mean??
Well… you need support, right!?
The community can and will help you, answer questions, solve some of your problems. But they will not come in to install, configure and run Postgres for you. You will need to select and integrate your specific selection out of the wealth of tools. You basically have a whole bunch of additional tasks to complete to get your Postgres platform sorted out.
Companies like EnterpriseDB can help you mitigate these tasks. This allows you to focus on the things you actually want to achieve using Postgres. In comparison to traditional database vendors, the overall price of your solution will absolutely, significantly reduce when using Postgres as your open source database engine.
A significant difference between Oracle (for instance) and Open Source support services is interchangeability. In the end, Oracle support can only be given by Oracle. They are the only ones that have access to the software sources and can look up (and hopefully fix) issues. In the support of Postgres, or any true community open source product, different companies can provide support. If you don’t like the company you work with… you switch. This drives these companies to be really good at delivering support! How is that for an eye-opener.
One of the superb advantages of Postgres is its native extensibility. I mean, think about it for a moment… having a relational database platform with the strength of Postgres, the strength of Oracle or Microsoft SQL Server for that matter. Postgres gives you more options to integrate a wealth of data sources, data types, custom operators and many more other extensions than you will ever need! The integration into Postgres is so solid, these extensions function like any other function in the core of Postgres.
And, rest assured, chances that you will ever be faced with having to build this yourself are extremely slim. There are 30 to 40 thousand developers working with larger and smaller pieces of code of Postgres. Chances are that if you find yourself challenged, somebody else faced and solved that challenge before you. That solution will then be available for you to take and use, solve your challenge and move on. That is also open source for you.
This capability is what makes Postgres ultimately suited to fit the central role in any polyglot environment, we see being built today.
Maximizing the amount of information from data available in multiple data silos in an organization. This is a challenge we see more and more often today. Integrating traditional applications such as ERP, CRM, with data-warehousing results, again combined with Big Data analysis and event-data-capture aggregates. This generates additional decision-driving information out of the combination of these silos. Postgres, by design, is ultimately suited for this. It saves you from migrating YUGE amounts of data from one store to another, just to make good use of it.
The open source Dogma “Horses for courses” eliminates double investments, large data migrations or transformations, it just enables you to combine and learn from what you already have.
End of part II
(originally appeared on Johnnyq72 blog - January 2017)
... View more
As with many stories, if you have something to tell, it quickly takes up a lot of space. Therefore this will be a series of blog posts on Postgres and a bit of Oracle. It will be a short series, though…
I have started with databases quite early on in my career. RMS by Datapoint… was it really a database? Well, at least sort of. It held data in a central storage, but it was a typical serial “database”. Interestingly enough, some of this stuff is maintained up to today. (Talk about longevity!) After switching to a more novel system, we adopted DEC (Digital Equipment Corporation) VAX, VMS and Micro VAX systems! Arguably still the best operating system around… In any case, it brought us the ability to run the only valid alternative for a database around, Oracle . With a shining Oracle version 6.2 soon to be replaced by version 7.3.4. Okay, truth be told, at that time I wasn’t really that deep into databases, so much of the significance was added later. My primary focus was on getting the job done, serving the business in making people better. Still working with SQL and analyzing data soon became one of my hobbies.
From administering databases, I did a broad range of things, but always looping back to or staying connected to software and software development using databases.
Really, is there any other way, I mean, building software without using some kind of database?
At a good point in time, we were developing software using the super-trendy client-server concept. It served us well at the time and fit the dogma of those days. No problems whatsoever. We were running our application on “fairly big boxes” for our customers (eg. single or double core HP D 3000 servers) licensed through 1 or 2 Oracle Database Standard Edition One licenses, and the client software was free anyway…
Some Rain Must Fall
The first disconnect I experienced with licensed software was the time we needed to deploy Oracle Reports Server.
After porting our application successfully to some kind of pre-APEX framework, we needed to continue our printing facilities as before. The conclusion was to use Oracle Reports Server, which we could call to fulfill the exact same functionality as the original client-server printing agent (rwrbe60.exe, I’ll never forget) did. There was only no way we could do this, other than buying licenses for (I thought it was) Oracle BI Publisher, something each of our clients had to do. This made printing more expensive than the entire database setup, almost even the biggest part of the entire TCO of our product, which makes no sense at all.
This disconnect was the first one. Moving forward I noticed and felt more and more of a disconnect between Oracle and what I like to call core technology. Call me what you will, I feel that if you want to bring a database to the market and want to stay on top of your game, your focus needs to be at least seriously fixed on that database.
Instead, we saw ever more focus for “non-core” technology. Oracle Fusion, Oracle Applications (okay, Oracle Apps had been there always), and as time progressed, the dilution became ever greater. I grew more and more in the belief that Oracle didn’t want to be that Database Company anymore (which proved to be true), but it was tough for me to believe. Here I was, having spent most of my active career focused on this technology, and now it was derailing (as it felt to me).
We saw those final things, with the elimination of Oracle Standard Edition One, basically forcing an entire contingent of their customers either out (too expensive) or up (invest in Oracle Standard Edition Two and deal with more cost for less functionality). What appeared to be a good thing ended up leaving a bad taste in the mouth. And, of course… the Oracle Cloud, I am not even going to discuss that in this blog post, sorry.
The Switch to Postgres
For me, the switch was in two stages. First, there was this situation that I was looking for something to do… I had completed my challenge and, through a good friend, ran into the kind people of EnterpriseDB. A company I only had little knowledge of doing stuff for PostgreSQL (or Postgres if you like, please, no Postgré or things alike please, find more about the project here), a database I had not so much more knowledge of. But, their challenge was very interesting! Grow and show Postgres and the good things it brings to the market.
Before I knew it, I was studying Postgres and all the things that Postgres brings. Which was easy enough in the end, as the internal workings and structures of Postgres and Oracle do not differ that much. I decided to do a presentation on the differences between Postgres and Oracle in Riga. I was kindly accepted by the committee even when I told them, my original submission had changed! A very good experience, even today, but with an unaccepted consequence. -> The second part of the switch was Oracle’s decision to cut me out of the Oracle ACE program.
It does free me up, somehow, to help database users across Europe, re-evaluate their Oracle buy-in and lock-in. Look at smarter and (much) more (cost)-effective ways to handle their database workloads. This finalized “the switch”, so to speak. Meanwhile, more and more people are realizing that there actually are valid alternatives to the Oracle database. After the adoption of the Oracle database as the only serious solution back in the early 1990’s, the world has changed, also for serious database applications!
End of Part I
(originally appeared on Johnnyq72 blog - December 2017)
... View more
Before uninstalling xDB, you need to make sure you've removed any SMR or MMR system using the xDB Replication Console, or Rep CLI: The following EDB Postgres Replication Server Guide section emphasizes this: Section 2.4.2 Design Considerations https://www.enterprisedb.com/docs/en/6.1/repguide/EDB_Postgres_Replication_Server_Users_Guide.1.11.html#pID0E0QNK0HA It states in the next to last bullet point: In general, the order of removal of a single-master replication system is as follows: 1) Remove the replication system logical components using the xDB Replication Console or xDB Replication Server CLI starting with the subscriptions (Subscription nodes) and then their parent components (Subscription Database nodes). 2) Unregister the subscription server if you no longer have any need for it. 3) Repeat the same process for the publications. 4) After all replication system logical components have been removed (except for possibly the publication server and subscription server) you can drop any of the physical database objects in Oracle, SQL Server, or Postgres. Do not drop the control schema objects manually, for example by using an SQL command line utility. Doing so may cause the xDB Replication Console and xDB Replication Server CLI to become inoperable. (See Section 10.3.4.3 if this problem occurs.) Deleting the replication system logical components using the xDB Replication Console or xDB Replication Server CLI automatically drops the control schema objects from the physical database. Also, when creating an Oracle publication, you should not use any existing Oracle user (like SYS, SYSTEM or XDB) as the xDB publication database user. Create a brand, new Oracle database user for this purpose. See the steps in: 184.108.40.206 Oracle Publication Database of the Guide: https://www.enterprisedb.com/docs/en/6.1/repguide/EDB_Postgres_Replication_Server_Users_Guide.1.24.html#pID0E0HSJ0HA Particularly, Step 1: Step 1: Create a database user name for the publication database user. The publication database user name must have a password, and it must have the ability to create a database session. The publication database user becomes the owner of the control schema objects that will be created in the publication database to track, control, and record the replication process and history. That way, if there is any corruption problem that is not solvable by the xDB Replication Console or Rep CLI, you can just delete that new, Oracle database user with the CASCADE option and all of the xDB publication data objects will be deleted with it. See Step 7 in 10.3.4.3 Deleting the Control Schema and Control Schema Objects: https://www.enterprisedb.com/docs/en/6.1/repguide/EDB_Postgres_Replication_Server_Users_Guide.1.66.html#pID0E0I50HA Step 7: For Oracle only: If the publication user name still exists, then log onto SQL*Plus or any other Oracle database administration utility and drop all control schema objects owned by the publication user. Alternatively, you can drop the publication database user along with its database objects using the cascade option, but the publication database user must be recreated and privileges reassigned if you intend to rebuild your replication systems. See Section 5.1.4 for directions on creating the publication database user. The following example illustrates use of the cascade option: SQL> CONNECT system/password Connected. SQL> DROP USER pubuser CASCADE; If you still have to manually drop each xDB database object from the Oracle publication, the following section lists all the individual objects: https://www.enterprisedb.com/docs/en/6.1/repguide/EDB_Postgres_Replication_Server_Users_Guide.1.25.html#pID0E0F6I0HA
... View more