Not so long ago, enterprises mostly had a few options when it came to databases: Oracle, SQL Server or IBM DB2. Things have fundamentally changed over the past few years leading to a marked shift towards adoption of open source databases. Here are a few key topics to consider for understanding differences and similarities between use of newer open source databases and more traditional legacy ones.
Licensing Costs: Proprietary licensing has become more complex and costly. Earlier, a database license would cost around $3000 per processor. However, to maintain a healthy revenue stream, traditional suppliers now charge license fees per core rather than per processor and have multiple editions, each having its own set of restrictions. This has raised the cost of deployment of databases significantly.
Non-Relational Databases: With the advent of a large amount of unstructured data being generated by an increasingly diverse set of platforms (which companies are deploying to communicate with both customers as well as stakeholders), non-relational databases like Redis Labs, MongoDB, etc. have come into prominence. This does not mean that traditional relational database management systems (RDBMS’s) are going away.
Because of these factors, increasing numbers of enterprises are reaching similar conclusions. In this fight between open source and proprietary databases, open source is punching well above its weight. However, although moving to an open source universe can be a rewarding experience, some due diligence in choosing the right platform is still required.
Agile Development: A big factor in determining the right technology is its scalability. A major factor contributing to this is the fact that most organizations today are adopting agile development models, where IT rather than being a centralized function is more of a functional organization. Each department has its own development team to experiment with proof of concepts before deploying the solution enterprise wide. Hence, the traditional approach to IT purchasing, where the central IT team was required to make a business case before embarking on a project has given way to smaller and functional IT teams deploying freemium / open source applications for prototyping and proving its success in production, thus making a business case naturally. Thus the choice of open source database is largely dependent on how scalable it is once its deployed enterprise-wide.
Savings: Enterprise-wide deployment means considering various factors that compare open-source databases to traditional databases in terms of security, reliability and other feature sets that are equivalent to Oracle, SQL Server or DB2. Hence open source database companies provide enterprise grade support for their product. However, even taking into consideration migration and support costs, switching to commercially supported versions of open source databases will still typically see saving of around 80% over a period of three to five years.
Limitations: All products have their limitations. For example, some open source databases may be less reliable with data storage and its querying model can be a bit weak. Cassandra can provide limited capability when it comes to ad hoc querying. Elasticsearch on the one hand has a robust querying environment, however there is a delay of two to three seconds on queried results. Postgres loads up very heavily as it does not update existing records, but rather writes a new version.
The point being that all products have compromises. The framework for taking the decision on choosing the right product should be based on what is the end goal that needs to be achieved rather than the ideal features that are desired from a product. Since most of the open-source databases are available to download for free, organizations have the flexibility to play around with them before taking the decision to choose what fits their needs the best. Even though the choices may seem to be a lot, it will basically boil down to a few options of databases that have enterprise grade support in terms of maturity of feature set, viability, security and reliability.