Big companies still stick to Oracle or DB2 because of legacy reasons. Open-source RDBMSs were not so mature at that time. I found senior management worried to migrate database if everything is running fine, even if they are paying to DBAs.

Secondly, with Closed-source RDBMSs like SQL Server, Oracle or DB2 (Enterprise), they can file a suit or blame someone if something goes wrong. Building an enterprise-class RDBMS and giving support to big companies is not a honeymoon.

In real-life cases I have seen customers giving warnings to database vendors when a bug disrupted their work. It costs customers millions.

Now coming to our good open-source era. With PostgreSQL matured enough, we have options to buy support and in the last few years I have seen we never felt a need of a dedicated DBA, though our company has appointed one to make their nights cool.

>“Proven reliability and advanced security features”
>– The only way I know if it works is if I can see the code and
> test it. “Proven” my ass.

You must be one of one thousands of 1% who look at the DBMS code. The rest of us would rather somebody else looked at the code and fixed it.
You rely on DB2 to do its job every time you go to your bank, book an airline ticket or make an insurance claim. Surprisingly, the people who run banks, insurance companies and airlines are able to do so without having access to source code.
On a personal note, I have full access to DB2 source code as I do to MySQL and PostgreSQL. I have 20 years of experience in DBMS. It never occurred to me that I need to look in to source to figure out what the problem is. Personally, I look at the traces to try to figure out who is the right person to look at the problem. I am willing to bet that I am more of a typical DBMS user than those like you who look at the source.
There are many out there who will claim there is a huge benefit from having access to source or being able to contribute code. Reality is, that most of these people are more in love with the philosophy than involved with the practice of open source. In 2009, the total number of contributions to MySQL was less than 40.

Your wife is asking a brilliant question. The answer for it is very similar to the question “why do I need a truck when I have a minivan”. If what you want to do is drive a bunch of kids to soccer practice (football for those of you outside of North America) then minivan is exactly what you need. But if you are in the construction business and you need a vehicle to carry your crew of 4 and half a ton of materials then you will want to look at the truck with extended cab. Think of DB2 Express-C as being a truck with extended cab and MySQL is a trusted family minivan. Sure you could rig the minivan with a trailer and load it up with your construction materials. You may burn out your transmission by hauling too much load but hey, it will give you a start in construction business with very little money at first. You are a Facebook/Twitter/Google, you have brilliant engineers who can afford the time to rig the hitch and a trailer. You may get really sophisticated with sharding and master slave replication, memcached and a dozen of other tricks to get your MySQL to similar performance and reliability that you can get with DB2. But if you are building a business and business applications you may do better by using a better foundation where all of that stuff is already built for you.

What we did with DB2 Express-C is made it follow the same business model as MySQL i.e. get it for free with very inexpensive optional subscription if you need it. We made that subscription even cheaper than MySQL. Why did we do this? Because we really wanted everyone to get an opportunity to get started with the technology that has a lot more legs and can take you much further than rigging your own trailer for a minivan can. We are nto under any allusion that the world will start using MySQL, nor should it. It is obviously the right platform for Facebook. But for those of us not building the next Facebook, DB2 Express-C and its business model of “Free license with low cost optional subscription” for the worlds’ most respected commercial DBMS this may be just the ticket.

The majority of software purchases are made by people that are not qualified, and the only thing these people care about is this: “Will this cover my ass in case something goes wrong?”

As a result, many small companies pay through their noses, because they end up over-buying, both in hardware and software.

Besides, the dirty work on Facebook it’s done by a large no-sql caching system.

They don’t use the stock product (the one you get with a “apt-get install mysql-server”). This kind of setups use highly tuned and customized (hacked) versions of the software.

Mysql is not the only opensource DB system.

I’m biased because I’m a DB2 admin, but I’d like to give a response to some of your statements.

“Proven reliability and advanced security features”
– The only way I know if it works is if I can see the code and test it. “Proven” my ass.

— I get your concern. However, most people/companies don’t have the time nor resources to go through the code or even understand it. Given that the codebase for the DB2 optimizer is larger than the entire MySQL product, this is impractical to say the least. DB2 runs on practically everything, has been doing so for a very long time and for me and most businesses this means proven stable.

Utmost performance;
–What does that even mean? Besides, open source systems (MySQL, PostgreSQL) run fast as hell.

— Simple, it’s very fast. He didn’t say it’s the fastest in any situation, did he? Don’t pay too much attention to the ridicilous TPC-C numbers, but the performance and the optimizer are very good. I have seen similar capabilities to the new “Join Removal” feature from PostgreSQL 9 for a long time in DB2. For a more simple comparison – DB performance comparisons are Hard – just check the count(*) comparison on this blog (google “android sheep db2 mysql”).

Ability to natively handle XML documents and data (some industries have to do so as a result of regulations);
–Makes sense. Yey for the compliance chicken! Not many do this, you’re right.

— I know a government organisation that stores the tax filings in XML because they change too much every year. I used the XML publishing options once because the memory Hibernate was using for this purpose was going to the roof in this particular case. There are good reasons to use XML as there are very good to not do it (popular ORM incompatibility comes to mind). I’m glad it’s there.

Vertical and horizontal scalability as their business grow;
–Again, MySQL and PostgreSQL are extremely scalable. See also: Facebook, Google, Yahoo’s 2 petabyte PostgreSQL database, etc.

— In the case of Facebook and Google, it’s no so much the database that is scalable, but the applications that are using it. Making the application responsible for handling database outages, replication, … is only available to companies of a large size with specific requirements (who cares about the loss of two facebook posts, really?). There is still a large userbase that just wants a place to dump and retrieve a lot of relational data really fast while knowing it will be kept safe there. In this case, things like DB2 HADR/PureScale, Oracle Data Guard/RAC, … really shine. All this sharding people program on top of MySQL? DB2 has provided this capability for years (http://planet.mysql.com/entry/?id=17130). Not for free though…

24/7 support from a reputable company that will truly stand behind the product they sell;
–Marketing garblygook. What koolaid are you drinking?

— I can tell you first hand that IBM support is competent. You quickly get a qualified person on the phone, the labs are not that difficult to reach through support if needed and around-the-sun support is available if you’re in really deep ****.

Overall TCO (which involves a lot more than just looking at the price tag for the software).
–Exactly. TCO is much lower when you can look at the goddamn code yourself.
— There’s a lot to TCO, but I doubt looking through the code yourself is going to improve it a lot…

“24/7 support from a reputable company that will truly stand behind the product they sell”

I agree with the poster taking issue with this. I’ve rarely had good experiences with commercial support; usually I find myself talking to a drooling moron who wouldn’t recognise a stack trace from a segfault and certainly won’t understand it. You have to battle past these people and their “help” to get to submit an obvious bug, with test case and crash dump, to someone capable of understanding it. So you land up not only doing most of your own support anyway, but then have to fight past the company’s support people to get bugs acknowledged and fixed!

I haven’t dealt with IBM for this, so perhaps they’re a rare exception to the general rule. I *have* dealt with Adobe (utterly pathetic), Quark (worse), Microsoft (surprisingly good especially for MSDN subscribers) and Apple (better than Quark, but that’s about it) and my experiences have not impressed me. Adobe in particular deserve special mention for selling expensive multi-user licenses for software they then completely fail to support even to the point of fixing reproducible and obvious bugs.

Most people use the “big company” argument more for cover-your-ass. “It’s IBM’s fault, not mine, that our database broke!”. Some try to claim it gives you someone to sue if it breaks – but I’ve never heard of anyone successfully suing Oracle, IBM, etc and their army of lawyers over data loss/failure. I doubt IBM are going to speak up by showing you cases where they’ve failed, either – they’ll settle quietly out of court if they don’t just stonewall.

So: I don’t buy the support argument. I’ve invariably had better support when I’m paying a 3rd party who doesn’t roll support into licensing for support, because they’re motivated to actually deliver on their claims or lose business.

Thanks for mentioning COUNT(…).

The reason PostgreSQL’s count() is slow is because of the MVCC design and the way tuple visibility information is stored. The MVCC design is part of what permits Pg to avoid having readers block writers and vice versa and what lets it minimize use of locking. The downside is that it has to scan the whole heap to determine which tuples the calling transaction can see in order to count how many the transaction can see.

I’d be interested in how DB2 handles this. Is it a a low-lock design where readers don’t block writers and vice versa, like PostgreSQL is? If so, does it use MVCC or some other approach? And if MVCC, how does it efficiently maintain a tuple count for a table?

There’s ongoing work in PostgreSQL that’s trying to use the visibility map (currently only used for autovacuum) to skip over sections of tables that’re known not to be visible to any transaction. That’ll help a fair bit. Hopefully in the longer run the work into covering indexes and supporting visibility information in indexes should cover the gap completely.

The complaints about COUNT(*) are mostly from webapps, though, and mostly when trying to get a count of records in the entire table. I rarely see “line of business” apps that seem to want to quickly and frequently find out how many records are in a whole table – as opposed to a subset of records, which is slower in ANY database.

PostgreSQL’s performance is far from perfect – but honestly, that’s true of everything out there, different systems just make different tradeoffs. To me, though, the bigger advantages of Oracle (and perhaps DB2) are in the areas of massively superior replication and clustering, better monitoring and tuning tools, and better tools for load accounting/user accounting/etc.

I must say, though, that DB2 has typically been undersold by IBM, who do an incredibly poor job of communicating to *technical* people why they should care, instead focusing on imposing it on IT by pushing it to management. It has a bit of a reputation as an expensive dinosaur, though not as much so as UniVerse. Some good documentation on its *technical* features that’s honest about what it’s not good at as well as what it is good at would go a long way toward making me, at least, have some interest in it.