Evaluate how comprehensive the API is. Is the API extensible? Can it do all the things you need the database to do?
* Security. Security is not just for restricting access to the database, it’s also about protecting the content in your database. If you have data that certain people may not see or change, and the database does not accommodate this level of granularity, this can be done using the application as the means of safeguarding the data. But this adds work to your application layer. If you are in government, finance or healthcare, to name a few groups, this may be a big factor in whether a specific NoSQL solution can be used for sensitive projects.
You should also consider how easy is it to administer user rights, roles and access. Can the database integrate easily with your LDAP or other Single Sign On solution you might have? What kind of granularity do you have? Is it at the database, “table” or record level?
* Management and Administration. An ongoing requirement of production applications is the management and maintenance of your database. How easy is it to manage and maintain the servers and the database software? How easy is it to manage situations where you need to add a server or storage resource? How well does the database perform when a node or disk crashes? Does a DBA need to be paged to take action or does the database architecture handle this gracefully without need of immediate intervention (assuming good capacity planning)?
How easily can the database integrate with your management system to alert you to any issues? How granular is the information you can get about the database, and is it sufficient?
* Open Source and Cost. Open Source is a big trend in evaluating software being used by organizations for many reasons. One is that open source is believed to be more robust, because everyone can view the code and provide feedback or contribute to the code base to shore up these holes. But in February 2015, one well-known open source database was found to have 10’s of thousands of unsecured servers among their users. It was not due to the code, it was due to documentation that did not advise the users to secure the server properly.
Another assumption is that Open Source costs less, since many projects can be done on the community edition and the community can answer many questions in lieu of paying for a support contract. This is true for some projects. You must be sure that you are evaluating all the cost factors, not just the “free” software. If you must integrate other core capabilities into the base open source database, you are paying for the time your team needs to do the integration or extra development work and continue to maintain that work. “Free” is not looking so free after all.
Sign up for CIO Asia eNewsletters.