We have yet to work on a project where Oracle was *critical* for some feature. PostgreSQL is rock solid for most applications, particularly intranet applications, and the price can't be beat. In addition, when considering this issue over a year ago, I asked this question in a thread,
" If money grew on trees, which would you choose Oracle or PG?". The discussion may be a bit dated since the PG community adds features at an amazing rate and with such quality, but even then the community held PG in high esteem.
I've also had this discussion with Janine who made very good points in favor of Oracle, that she's relayed above. There's something to be said for using an industry standard application (unless, of course, it's a buggy, security-challenged POS whose vulnerabilities threaten the world's network infrastructure.) If your boss is afraid of open source software and he is willing to spend money to allay any potential fear, Oracle can't be beat.
There are an increasing number of companies that provide support for PG, including Red Hat. So this issue is slightly less extreme. But those companies, like most open source companies, are usually small shops because they tend or can't charge ridiculous "enterprise" rates. And the numbers of massive and truly mission critical PG installations are growing daily, from Afilias system that manages the .org and .info registries to some very mission critical apps that Musea has built for nonprofit service agencies.
So from my experience, going with PG is a safe choice but not without needing to do some "selling" to management. Oracle is a great and "can't lose" DB from a technical perspective, but it's tough and expensive to have and maintain. PG is a relative breeze in both of these regards, but it doesn't have the industry support or give the trade-mag-reading CTO the warm and fuzzies.
Either way, since you're in Portland, if anything goes wrong you can call up Super-Don to rescue your data. All you have to do is have a couple of pitchers of good beer and he'll manually recover the bits in the db.
talli
