But I'd like to know how many other reasons there are.
1. We know it well. It is easy to develop for because it's just SQL on a single server.
2. In traditional ACID transactional processing, our core business, it performs quite well. Even mediocre queries often perform well. We've never had a customer or use case outgrow a single oracle db yet. Part of the reason oracle is so expensive is that you need very few servers if you properly design your db architecture.
3. Our customers already know how to deploy it, which makes rolling out our product much easier. It is proven and well-understood technology. Often they already have an oracle server for us to share.
4. Our product is designed around oracle and ACID. Migrating to an alternative would be painful (if moving to an ACID alternative like postgres) or horribly painful (if moving to a BASE database).
I think people often make the mistake of looking at the single license cost of sql server or oracle and assuming they're more expensive than the <insert favorite alternative> nosql db of the hour when you add up all the costs. I used to mock microsoft for bringing up TCO, but i have to admit it's a fair point. Stackoverflow runs off of a mirrored pair of sql server instances. You have to wonder how much servers they would need and how much extra development it would have cost to handle the same load on an eventually consistent alternative.
My personal opinion is that you have to choose up-front whether to scale up or scale out. Scaling up means paying for oracle or sql server and having a simpler development model because you have a single db instance. Scaling out means going for nosql and taking some of the reliability and synchronization work into your codebase. I don't think companies like oracle are selling the development advantages of scaling up very well, probably because they're not developer-oriented. The strategic mistake oracle continues to make is to alienate devs. They could build a strong case for oracle over nosql, if they cared about developer relations.
Ignoring some of the specific details and focusing on the underlying point here:
Having had to work with both ACID and BASE systems extensively, the above point strikes a chord with me. Those of you who haven't dealt with both in anger, take heed of it.
BASE is a lot of code and reasoning to work with properly, and you're sacrificing the many knobs, tools, and easy ad-hoc queries (read: simpler debugging) that the common ACID systems have to get it. Common ACID systems are well understood, so there are many fewer surprises in wait. Furthermore, those systems are mature and have walked the inescapable trail of tears to get there; data is the lifeblood of most businesses, so it's not a place to take risks.
I'd rather work with ACID. BASE is for when you really need it (and when you really need it, you'll know).
It's a bit like blaming Boeing for gravity, then swearing only to use fleets of microlights to relocate your shipping containers.
http://www.oracle.com/technetwork/products/nosqldb/overview/...
Considering they really don't need ACID and the amount of complexity their cache layers add, it would probably be much simpler to develop, maintain and operate. Seriously, their model is the textbook example for non-relational datastores.
I haven't worked enough with postgres to know what loads it can handle, but i'm sure there are plenty of cases where a single instance is just fine.
* Large sales teams; don't underestimate the impact that a sales rep can have on a company's technology purchasing decisions, especially outside the world of engineering-heavy startups
* An ecosystem of engineers in the U.S. and all around the world who are provided training and certification specifically in Oracle products - this gives them an incentive to suggest Oracle products to the companies they work for (or to keep these products in place)
* A perception (sometimes correct, sometimes not) that software for which the code is tightly controlled and kept by a company with a good reputation in enterprise computing will be 'better' in some senses (performance, security, usability) than open source alternatives
Sometimes it might come down to things like NoSQL vs relational, ACID compliance etc, but bear in mind that there is a huge ecosystem of (less-tech-savvy) companies out there each of which need HR, accounting, and a myriad of other internal or hosted services - and Oracle's sales teams (as with any other sales-oriented company) will have pipelines built around these companies as prospects.
A company like Stackoverflow is nothing like a large corporation in terms of apps/DBs.