2010 was a very good year for open source databases, with the top RDBMSs like Oracle's MySQL and PostgreSQL showing momentum with impressive customer gains and new releases that delivered much-desired functionality. Everything points to similar energy in 2011 with the top analyst groups and big-name system integrators like Accenture proclaiming "the coming age of open source." A study done by Accenture in late 2010 showed that more than two-thirds of organizations anticipate increased investment in open source, with more than one-third expecting to migrate mission-critical software to open source in the next 12 months.
Such growth is impressive for sure. But, while it's good to see the use and benefits of open source databases becoming more widespread, IT managers and database professionals need to be smart about when and where they adopt open source databases in their organizations. Each particular application scenario will have its own unique set of requirements and demands but there are some general guidelines you can use to determine when you want to consider an open source database and move into a formal proof-of-concept phase with such software.
When It Financially Makes Sense
The cost savings that open source database software provides isn't hype, but instead is very real. Savings in excess of 80-90% can be experienced in certain circumstances. And because the top open source databases use ANSI SQL, provide good tooling, and are supported by lots of third-party software, there's very little learning curve involved.
However, it may not always make financial sense to use open source databases. Some companies employ site licenses of their proprietary database software and have installations where such a need will not change anytime in the near term. For these situations, deploying more servers of a particular database incurs no real extra financial outlay and negates the financial benefits that open source databases offer.
When You Don't Use (Or Expect to Use) Many of the Features of Your Current RDBMS
Many years ago, Forrester Research did a study and found that 80% of database installations only use 20% of the features the database software provides. That's a pretty eye-popping finding considering that, outside of needing formal production support, the number-one reason companies continue to pay a database vendor after their initial purchase is to get new enhancements for the product.
Open source databases make good sense for a new project or current application when you need the core capabilities that a good RDBMS provides but don't have a requirement for the esoteric features that tag along with the big-name databases. Understand, however, that you need to be smart in your evaluation so you don't discount a feature that you'll eventually have to do lots of extra work for because it's missing. But as long as you have that safety net in place, if you determine you don't need all the bells and whistles of a proprietary database, then you should look hard at using an open source alternative. And keep in mind that the top open source databases have extremely robust feature sets, so most times, you won't have to worry about compromising at all on this front.
When You're Developing New Applications
New application development is the most fertile ground for an open source database. That's not to say that full rip-and-replace projects (where a current proprietary RDBMS is swapped out for an open source database) don't happen and can't be successful. I know many customers that have done full migration projects and are delighted with the end results. But new application development projects are where it's most easy to introduce open source databases.
In particular, new applications that use a hybrid database approach have proven to be a very successful arena for open source databases to strut their stuff. In a hybrid database scenario, the underlying application actually uses two or more sets of database software where each makes the most sense. For example, a web travel site may use a scale-out architecture with many servers and an open source database to scale their lookup and read operations, but then use a proprietary database on one server (with a hot backup standby) to actually book and keep customer travel data.
Most companies dip their toe in the water with open source via a small, new departmental application and if it proves to be successful, they expand the use of open source outward from there.
Conclusions
There's no question open source database usage is on the rise, but that doesn't mean they're right for every occasion. However, if you find that the current proprietary database you're using is overkill for what you need, that you have many new applications that you need to develop, and that you stand to save a measurable amount of money by deploying an open source database, then you should feel comfortable that you're on pretty solid ground for moving ahead with a more thorough evaluation.