[godzillabrennus]

My experience has shown me that Companies will buy/use technologies based on two pillars, Trust and Value. The pillar of trust takes an enormous amount of time to establish and can be decimated very quickly. Trust is about 95% of any buying relationship. Companies will even buy products they don't understand the value of because they trust the vendor it comes from.

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.

[acdha]

> Consider that if 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.

[X86BSD]

Im curious how many who claim the "No one ever got fired for buying IBM" thought process about paying for Oracle for their support or so they can blame someone else for being lazy and incompetent have ever USED oracle support. Waiting a week or longer for a patch with no work around is not uncommon, and not exactly something I would pay for.

[tmd83]

Yup. I have never had much luck with support except sort of some big known problems or something where you can afford a lot of time. Most of the time you end up figuring out the problem or a workaround long before it gets pushed to some real engineer. And even when you diagnose the problem partially they will simply ignore you and ask rota questions and 5 days later give you the solution you have come up with in case they come up with one.

[acdha]

I think those happen at completely different levels and there are a lot of places where the communications process either doesn't work at all or has significant translation issues. Here's what it looked like at one job:

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…