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 systems integrators like Accenture proclaiming “the coming of age of open source”. A study done by Accenture in late 2010 showed that more than two-thirds of organisations (69 per cent) anticipate increased investment in open source, with more than a third (38 per cent) 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 open source databases being used more widely, IT managers and database professionals need to be smart about when and where they adopt open source databases in their organisations. Of course, each particular application scenario will have its own unique set of requirements and demands, so it’s difficult to provide an exhaustive list of criteria for whether an open source database will be a good fit for a particular project. However, there are some general guidelines you can use, to determine when you could consider an open source database, and move into a formal proof-of-concept phase with such software.
Your current RDBMS is under-utilised
The first hint is 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 per cent of database installations only use 20 per cent of the features that the database software provides. That’s a pretty eye-popping finding, considering that outside of needing formal production support, the No 1 reason companies continue to pay a database vendor after the initial purchase is to get new enhancements for the product.
Having worked as a DBA for about 15 years before I got into making software for DBAs, I can attest to the truthfulness of Forrester’s findings. Whether it was DB2, Teradata, Oracle, SQL Server, Sybase, MySQL, or PostgreSQL, in the vast majority of applications that were either developed in-house or purchased from the outside, I found myself using the core feature set that defines an RDBMS (e.g., tables, indexes, foreign keys, etc) continuously, but only rarely did I find the need to employ some of the more boutique features that came bundled with the database. That’s not to say that I didn’t end up using such features from time to time, but it was not often.
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 initially discount a feature that you’ll eventually have to do a lot of extra work for, because it’s missing.
But as long as you have that safety net in place, if you determine that 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 (PostgreSQL, in particular) 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 easiest to introduce an open source database.
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 travel website may use a scale-out architecture with many servers and an open source database to scale its look-up and read operations, but then use a proprietary database on one server (with a hot back-up standby) to actually book and keep customer travel data.
Most companies dip their toes 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.
When it makes sense financially
The cost saving that open source database software provides isn’t hype, but very real. Savings in excess of 80-90 per cent can be experienced in certain circumstances. And because the top open source databases use ANSI SQL, they also provide good tooling, and are supported by lots of third-party software. There’s very little learning involved.
However, it may not always make financial sense to use open source databases. Some companies employ site licences of their proprietary database software, and have installations where such a need will not change any time 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.
There’s no question that the use of open source databases 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 significant amount of money by deploying an open source database, then you are on pretty solid ground to move ahead with a more thorough evaluation of open source options.
