Five Ways Open Source Databases Are Limited

Two of the reasons to deploy an open source database are cost and philosophy. Philosophically, the open source movement subscribes to the notion that having community-developed product creates a better product, and/or “contributes to the world in a better way.” The other reason is cost, which usually means “free,” or at least no-charge for the software database license.

Putting aside the philosophical discussion, that leaves cost. And at first that seems like a silly question. Why would you ever not want free? But it turns out it’s not so simple. Of the top 5 databases deployed–Oracle, MySQL, Microsoft SQL Server, MongoDB, and PostgreSQL–two are commercial, and the other three open source. But the two commercial databases represent the vast bulk of deployments, especially for mission critical deployments. Why is that?

Once an enterprise deploys an application that becomes mission critical, e.g., significant money starts changing hands, the requirements for the database underlying that application become a lot more robust, and scrutinized.

Here are five reasons commercial databases are the best fit for mission critical applications:

1. Support

You get a higher level of support with a commercial database than an open source database. Commercial databases provide professional 24/7/365 support, while open source databases provide a community support model. So enterprises can expect an immediate support response from their commercial database vendor, which is essential to a mission critical application.

For e-tailers, downtime can be measured in tens of thousands of dollars per minute. In addition, enterprises leveraging commercial databases have access to up-to-date professional documentation and training. Now whereas some third-party vendors provide support for open source databases, that can represent quite a cost differential from “free.” And worse, your third-party support engineer for an open source database is not in a position to drive product changes, whereas with commercial database, support engineers are.

The CIO responsible for a mission-critical application needs to ask, “Does this database have enterprise-grade 24/7/365 support?” Similarly, she should ask “Is there an SLA to guarantee that level of support, and are there any warranties or liability guarantees with that support contract?” In general, open source databases do not provide this kind of commercial database support.

2. Vendor Persistence

Commercial applications reliant on an operational database requires a significant investment in money and time, for development, deployment and on-going maintenance. Thus, knowing that your database vendor will continue to be in business is a significant concern. A commercial database vendor’s business model is product revenue-based, giving it a strong financial footing. Open source databases either have no revenue source or rely on services revenues.

Open source projects also have uncertainty and raise question like “Who decides the direction?” “Is it for sale?” and “Is it still being actively maintained?” To protect your investment, you really want to be confident that the operational database vendor will stick around, and continue to maintain it.

A notable exception in the open source world is MySQL, which was acquired by commercial database company Oracle. Wouldn’t that solve the vendor persistence question? They can afford to spend internal resources to develop MySQL, right? Actually, the answer is so uncertain, some enterprises are migrating to alternatives like MariaDB and ClustrixDB, especially in Europe. No one knows the future of MySQL except Oracle, but there’s clearly doubt in the marketplace.

3. Input Into New Features

In the commercial world, features follow commercial demand. If, as a paying customer, you want a new feature, you contact your account manager or log a bug, and you’ll get an answer as to whether and when you will get that feature. You’ll be able to know when your enhancement request will be scheduled on the roadmap, and you’ll be able to plan your business campaigns accordingly.

On the other hand, in the open source world, it’s up to the community. If the feature is “sexy,” you might get it sooner but no commitment as to when. If you need a feature that the open source developers don’t find “sexy,” then you may wait a long time or need to develop it yourself. And, depending on the Open Source License, you may have to release that code into the wild, for current or future competitors to use to compete against you.

4. Tested, Stable Products

Vendors rigorously test their products before selling them. Enterprises need high levels of confidence in the stability of the database supporting mission critical applications. The performance of the database directly affects the stability, reliability, and customer satisfaction of those applications. And perhaps even more importantly, knowing your commercial database vendor’s product roadmap, let-alone having direct input into it, can provide a significant competitive advantage.

With a commercial database, the vendor is wholly dedicated to ensuring that each patch is stable, and provides clear value to your enterprise workload. You have a direct, personal relationship with the company who employs the developers enhancing and maintaining that database code – it isn’t going to get flakey on you.

In the open source world, testing varies widely. The roadmap can change frequently, making application releases difficult to plan. Correspondingly, tracking point-releases and bugfix uptake can be burdensome. Either you don’t know what to install and when, or your DevOps personnel need to take time daily to keep up to date with what is coming down the pike. Do they want to uptake that new open source patch? Are the new features worth the risk of potential service interruptions?

5. Reliability

Perhaps the biggest reason the largest e-commerce sites and web applications are deployed on commercial databases is the cost of failed transactions is simply too high to risk “free.” If an e-commerce checkout breaks, a customer could try to buy something that is no longer available, or they could be charged multiple times. The latter scenario is a very serious problem. Imagine the damage a tweet like “ABC store charged me even though I never received the product – jerks!” Negative social media can escalate such a failure from one upset customer to global branding issue.

Open source databases may be appropriate and cost-effective for non-mission critical deployments where lost data or failures are not catastrophic. Social media and proof-of-concept deployments are ready examples. But when you’re ready to deploy a mission-critical operational database, it’s important to step up to a vetted enterprise database, which has proven 24/7/365 supportability, backed by a long-term professional vendor who is attentive to your feature requests, and provides tested, stable, and reliable code.

About the author: Dave Anselmi brings over 16 years of product management, integration, and project management experience in e-commerce and database technology to Clustrix. Prior to Clustrix, Dave was at Oracle, where he held the position of Senior Product Manager for Siebel and Fusion E-Commerce. Previously, Dave was an instructor of RDBMS at UC Berkeley Extension.

Related Items:

Why Pay for Analytics When Open Source Is ‘Free?’

The Double-Edged Sword of Open Source