[calpaterson]

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.

[acdha]

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.