I thought you were already a huge Postgres advocate? Or do you mean 'upsides to postgres that appeals to heavy oracle sites'?
/edit Perhaps that wasn't you...
So #1 benefit of Postgres for Oracle shops is transition cost.
It's cheaper than Oracle (by sometimes substantial amounts), and relatively painless to switch to. A lot of code can move unmodified, all the same platforms, and often even the same teams of folks in the same jobs.
Postgres scales very well, at the very least it can handle 90% of a given company's Oracle load with no real issue.
Things like clustering, backups, failovers, and reporting systems can be re-engineered to work in similar ways on Postgres, though some will require substantial hackery.
The #2 benefit is stability. Oracle has a very bad track record (especially lately) when it comes to patching and supporting older databases. If you just want a DB to sit in the corner and work for a year, with push-button easy security patches at most... Oracle isn't really the product anymore. Oracle CPU (critical patches) are cumulative now, and the bloat is getting out of hand. I recently just installed a set of patches that were almost an extra 5GB for the footprint... minor for a 20TB database, but ridiculous if you're thinking of thousands of small distributed hosts.
What's Oracle's patch deployment strategy now? The last time I had to deal with it was around 2008, when a security update was a tarball with a README file telling you which files to copy where. I've heard it's improved considerably since then.
Not a ton different, if you've used OPatch already. Basically it copies around files, runs a bunch of perl, runs a bunch of sql, and then you run the usual patch upgrade scripts at the end. The in-place patching is safer and smoother in 12c than it was in 11g, but the cumulative patching has really gotten out of hand.
For example - on a QA system we were running a couple of custom one-off patches delivered by Oracle Support. These blew up the entire patch process. I had to stop, back them out, re-patch, then re-apply the one-off patches.
Oh, and 12c is a seriously whiny bitch about XDB. Just for added fun.
So #1 benefit of Postgres for Oracle shops is transition cost. It's cheaper than Oracle (by sometimes substantial amounts), and relatively painless to switch to. A lot of code can move unmodified, all the same platforms, and often even the same teams of folks in the same jobs. Postgres scales very well, at the very least it can handle 90% of a given company's Oracle load with no real issue. Things like clustering, backups, failovers, and reporting systems can be re-engineered to work in similar ways on Postgres, though some will require substantial hackery.
The #2 benefit is stability. Oracle has a very bad track record (especially lately) when it comes to patching and supporting older databases. If you just want a DB to sit in the corner and work for a year, with push-button easy security patches at most... Oracle isn't really the product anymore. Oracle CPU (critical patches) are cumulative now, and the bloat is getting out of hand. I recently just installed a set of patches that were almost an extra 5GB for the footprint... minor for a 20TB database, but ridiculous if you're thinking of thousands of small distributed hosts.