Commercial database systems versus open source database systems [closed]

Question

Can anyone tell me what are the reasons for buying a commercial database system and not using an open-source free version?

The reason for my question is that:

1. Commercial systems cost upwards of 10.000 $
2. The most popular websites (e.g. Twitter, Facebook, etc.) all use some open-source engine (for e.g. Twitter used MySQL and is switching slowly to Cassandra), thus proving the reliability of such systems

Is there any financial and/or technical advantage that commercial systems have over the open-source alternatives?

Answer 1

This really depends on your requirements. Many systems built on top of open source products are rock solid.

Note that your example does not impress me - Twitter is not reliable at all by my customers' standards - it has frequent downtimes, it loses tweets and followers, its search is not 100% correct etc. I work in finances, and my job is to develop robust and performant systems. In some (but not all) of the scenarios I encounter, open source PostgreSQL could get the job done just as well as closed source Oracle, in terms of speed and robustness.

If your needs are more or less standard, than you can save a lot of precious time if you go for Oracle or SQL Server, as you might spend less time on setting things up and maintenance. As such, your investment in licensing costs may pay off quite soon.

If, however, your needs are not completely mainstream, then open source is your friend. Open source products can innovate much faster. You don't have to persuade someone that your scenario is not "convoluted", you can get a fix right away instead of waiting for years. If you really need something, you can do it yourself.

Answer 2

As with any other piece of software, it's a question of features vs. cost.

Enterprise class commercial databases (Oracle, DB2, and SQL Server primarily) generally have a variety of technical and non-technical features that are very helpful for large companies. Focusing just on the non-technical, commercial databases will generally have a much more mature support organization (both from the standpoint of dealing with bugs and support issues as well as being able to call in pre- and post-sales folks for demos or to discuss architecture options). There will generally be more people in a given market that are experienced with the various commercial options. And companies generally already have a fair amount of expertise in-house. Then, of course, there are the technical features but there you have to get into much more detail to figure out which features of which databases are going to be important to any particular project or organization.

The market for database engines in a startup (particularly a technology startup) is generally rather different than the market for database engines in an established company. A startup is generally going to prefer the cheaper option even if it requires more development time up front both because cash is precious to a startup and because developer time is generally less so. A technology startup is also likely to want to invest a lot of time customizing their particular technology stack because they have a vision where their technology stack provides some sort of competitive advantage. And remember, for every startup you see that has managed to scale up like Facebook or Twitter, there are probably thousands that failed (not always because of their technology choices, of course).

While it's quite possible that something like Facebook can write quite secure and scalable PHP code on top of a database engine that provides eventual consistency (that is, everyone will eventually see your latest status update but it may take some time), that doesn't necessarily imply that it's a great idea for the next company to mimic that infrastructure. You're not looking at the hundreds of sites that failed because the PHP developers didn't do proper separation of concerns and created brittle code that couldn't adapt quickly enough when the business needed to pivot to a new business model. You're not seeing the extra effort that would be required to bring a company full of developers up to speed on a new database engine or the headaches that most companies would have trying to go out and hire a Cassandra expert if they wanted to ramp up development. And it doesn't imply that the technical assumptions that underly one company's technology choices apply to another company-- your bank ought to care a heck of a lot more that everyone is always seeing a transactionally consistent view of the data than Twitter cares about whether you can see every single tweet someone has made.