PostgreSQL doesn't have the network of value added resellers and internal sales reps that Oracle has amassed. These are people that engineers dismiss but management often see them as a support tier for their customers of a product. That tier builds trust.
If you try to introduce your product/service to an enterprise B2B market with an established market leader and intend to sell or distribute entirely off of value alone you will lose nearly every time. In smaller companies that can't dream of licensing Oracle the risk is worth the reward, it's not like they have a choice and they then grow an in house knowledge to be that support tier if they scale.
Consider that I f something breaks at a big enterprise it's likely to cost millions of dollars in lost payroll while it gets fixed. Big companies would rather mitigate the risk and buy a supported and proven product. They trust it.
One facet to trust is your personal career: as the manager who signs off on this, you can trust that if anything goes wrong Oracle will aggressively defend your decision — people, including high-level managers, will show up on site to defend the decision and promise to fix whatever went wrong, consultant reports by the pound, etc. If you go with Postgres, you're going to have to do more of that yourself and if the amounts were at all significant, you can be very confident that Oracle will have people telling your C-level management that this never would have happened if you'd gone with them. Even going with Microsoft can be seen as “risky” for that reason.
My level:
1. Internet Explorer 8 is released. Our users start to get the automatic update and our very expensive Oracle reporting app breaks.
2. I contact Oracle's support and get a very snotty customer “service” person:
“I noticed a bug in your JavaScript code which now triggers an exception on IE8.”[1]
“We don't beta-test Microsoft's software for them. We'll start testing IE8 when it ships.”
“That was last week. How's the testing going?”
pause
“We'll get back to you”
“Please do. I deployed a patch but am worried there are more subtle problems.”
3. <days pass with no contact>
4. “Hi, this <senior support manager>. Can you give us a copy of the patch you mentioned so we can distribute it to other customers who are dead in the water?”
5. <time passes>
6. “You'll need to upgrade to $NEXT_MAJOR_VERSION, which was just released and is a paid upgrade”
The executive level where the decision to buy was actually made:
“Hey, heard you guys had a problem or two but the support group worked it out”
“Yeah, the usual. Are we still on for our normal tee time?”
The problem was that the executives didn't have any experience somewhere dramatically better functioning and both the outside sales team and their staff who had invested much of their professional development in that stack had an incentive to downplay problems and come up with reasons why any particular outside comparison wasn't valid. No large organization works exactly the same as its peers and so you can always come up with some argument for why they can do something but it won't work for you. The only thing which seems to disrupt that is either a failure too big to be excused or the emergence of an alternative which is either dramatically cheaper or does something new such as support mobile/BYOD or a cloud service which removes the need to have the staffing and equipment in-house for a major app.
1. This was actually a neat class of failure: the IE7-emulation mode solved most of the display problems but it was still using the IE8 JavaScript engine, which raised an exception when a library attempted to set zIndex to a completely invalid value like null, unlike the real IE7 engine which simply ignored it. I pity whoever at Microsoft maintained the test suites for those enterprise compatibility modes…
Nobody is out there on the Postgres side doing the same, so that decision maker doesn't even know who they are. Then when someone suggests pgsql for something, the first question is, "Where do we get support?" Everyone then looks around the room and starts searching the web for support.
There is no question if and who will support you with Oracle (which is why I will never choose them).
Just believing a well-known company which presents their product as "the solution to all your problems" does not seem very clever to me.
I know that when I don't have the knowledge in a particular area, say payment processing, and I can only think of a vendor or two off the top of my head, it becomes someone's assignment to bring me the pros and cons of the major vendors and maybe a couple of the upstarts- including getting on the phone with them if necessary. The ultimate decision will be a combination of that person's recommendation vs. any business problems that may prevent a relationship (say some certification or SLA forced on us by the client).
There is also the psychology aspect of a well known name. They must be a well known giant because they are good, provide the best, or provide something the others can't- right? Now, WE know that mostly Oracle doesn't do these things. There are a few cases where they have kind of engineered a way to be the only one who does the thing (then got someone to make it a requirement in their project). We know they're generally abusive, and awful to work with. A not very technical decision maker just knows Oracle is a big name. Just like SAP. I'm not saying it's an excuse, it just is.
It will cost a lot in time and dollars to actually get what you want and you will not want to litigate Oracle.
The other common reason is if you'll be deploying some existing application on top of your RDBMS and it either only supports Oracle (ie: it uses Oracle's proprietary language somehow or simply not ported to Postgres) or you already have lots of Oracle DBAs. Most big organisations are very brownfield so the technology choice is path dependent.
At one previous employer, we had to deal with several hours of downtime daily because they kept not getting the $$$$ budget needed for Oracle's online backup product and so it went down for how ever long it took to write data out to a poorly configured tape backup. Trying to use MySQL or Postgres happened by necessity but was heavily FUDed over what might happen and all of the (internal) users had just been trained that the systems weren't available before 7:30 AM.
Once they get the shoulder in the door, they push to expand the database horizontally in the organization.
Microsoft has a similar strategy with CRM and SQL Server. SQL Server drives their corporate success.
Postgres vs. Oracle, etc is a pointless argument because it's answering the wrong question.
The most important difference is that SQL Server has everything that Oracle has to offer at a much, much cheaper price.
I agree that comparison with postgres and mysql are pointless. They offer a tiny fraction of what enteprise products have. If you need it, you will know.
One thing that comes to mind is Linux (or Solaris, HP-UX, or other nixes) support. SQL Server is essentially Windows-only.
[1] https://blogs.microsoft.com/blog/2016/03/07/announcing-sql-s...
https://technet.microsoft.com/en-us/library/ms184286(v=sql.1...
Oracle stores the old version of the row in a rollback segment.
According to the following article, "only changed values are written to undo whereas PostgreSQL/SQL Server creates a complete new tuple for modified row. This avoids bloat in the main heap segment." [1]
1. http://www.enterprisedb.com/postgres-plus-edb-blog/amit-kapi...
Both Oracle and SQL Server has some way to restrict the growth of version information whereas PostgreSQL/PPAS doesn't have any way.
(Don't speak to me about SQL Server. Of all the brain dead ideas, implementing storage in the TempDB for snapshot isolation!)
It is a similar dynamic with SAP another much detested system by everyone who is not in IT or works as a consultant. It is amazing to me, pretty much everyone who actually works in an SAP (or Oracle) system detests it but cannot get IT to provide an alternative.
I would assume Oracle has a very strong presences in Russia in those terms. Unlike Postgres until Postgres Pro.
More details (in Russian): http://obartunov.livejournal.com/181484.html
Postgres and others are working on solutions for this, and I find more shops look for alternative solutions instead of paying for Oracle licenses.
[0] https://wiki.postgresql.org/wiki/Parallel_Query_Execution
No one was ever fired for choosing Oracle.