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.
> 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.
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.
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.
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…
Honestly (having been through plenty of meetings where this type of stuff happens) it's because Oracle has someone out there spreading the word to
The decision makers. The Oracle sales team isn't converting developers, they're in the ear of the person who signs the check.
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).
I'd say it's less 'smart' and more due diligence. I agree that you should know at least SOME alternative options to things. We're seeing more tech Managers/Directors/VPs/whatever that used to be engineers or architects and I think we'll have more people that fairly recently (or still do) had their hands dirty in project work. The new wave of leaders are much more technical than the previous wave of leaders. But the problem still remains that once you've been away from the daily low level work, things move on without you. There will always be some disconnect. I think the new wave of leadership will better know that and hopefully respond a little better by having people propose alternatives to them, personally finding alternatives, etc.
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.
You are right, but there's a way around the argument that allows them to still make a bad decision. It's called management by committee. They don't need to provide a good fit-gap analysis, sound points for the plan or quantify why it's better. You will simply hear that a group of smart people have concluded that it's a "good plan" and that they consulted with Oracle and their own experts who are also absolved of any responsibility since lack-of accountability is built-in to their contract.
It will cost a lot in time and dollars to actually get what you want and you will not want to litigate Oracle.
A common reason seems to be that the person in charge of procurement puts importance some operational aspect that Oracle has that other RDBMSs do not have. For example, some specific availability scenario that Oracle RAC solves, some security feature like row level security (which Postgres does have now) or some disaster recovery thing in RMAN. Most procurement processes only consider price once all criteria have been met so a common "attack vector" for an Oracle salesman is to get some criterion added that only Oracle can provide :).
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.
I think you're right, particularly about the apps – if you don't work at a large shop it's easy to forget how many businesses run the various financial apps which Oracle sells, and such apps tend to be used by senior management so e.g. the CFO is voting against changes unless there's a really good justification. Once you've got it in house, the argument will be that you don't want to have to hire experts for more than one database, which is how some people end up running a normal web app on Oracle because it's the only supported HA/backup/etc. option offered by the central IT group.
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.
The comparison with SQL Server is not very sound. SQL Server is MUCH cheaper. I would venture to say it is more performent and is on-par with features (certainly will be after the next realease). Moreover. SQL Server is not brute forced in the way you say Oracle is, especially with CRM. Maybe something like that happens with the ERP products, but much more mildly.
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.
Yes, that's why I said this statement will be true for the upcomming release. I don't think this particular feature is that important anyway. Being Windows only has allowed SQL Server to e much more performent in many cases. Cost is not a factor.
The main advantage Oracle has over SQL Server in my opinion is that Oracle has tablespaces and multi-version concurrency control baked in, whereas SQL Server has ONE TempDB and snapshot isolation relying on that one TempDB.
On the nose. SQL Server is a great product, but their MVCC is basically hacked in. They're also lacking in the features Oracle has around their Undo tablespace, and auditing.
What exactly does that mean? MVCC is definitely different in Oracle and Postgres, but that doesn't mean it "takes over the heap" it just means it stores a new version of the row in the same heap. Later on an auto-vacuum process clears out the old heap page, or sometimes on demand when a select, update or delete accesses the row.
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]
One overlooked aspect is the career prospects for someone in IT working with an Oracle system. It is a network effect where career prospects dictate the system chosen which in turn makes the system more prevalent. Soon they are known as someone who has overseen an installation/maintenance of an Oracle system and can look forward to a stable career. In contrast someone installing a postgres system will not have the same opportunities.
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.
If your operations are tied in some way to government, it might be required that software you are using have legally recognizable developer or owner, officially certified by competent government structures (e.g. in terms of being secure) and/or has someone who is contractually obliged to help you resolve any issues you might face while using it.
I would assume Oracle has a very strong presences in Russia in those terms. Unlike Postgres until Postgres Pro.
IMO the principal advantage commercial RDBMS platforms have over the open source ones is query parallism [0], which can be a big advantage for certain query workloads.
Postgres and others are working on solutions for this, and I find more shops look for alternative solutions instead of paying for Oracle licenses.
Have you used apex 5. I've seen apex applications created by good developers (who can code with sql, pl/sql and javascript) which have been nicer, more reliable and definitely more performant than some java or.Net Web apps.
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.