Applications generally look for NoSQL database for one of the following reasons:
- Flexible schema or schema on read. Data or its type cannot be predetermined. In Informix NoSQL, it's accomplished via JSON and BSON type, added natively into the database. Just like LVARCHAR. Not only you won't know the column names (in this case KEY-VALUE pair, you won't know their type as well). It's not just you're able to store, you need to index and query as well.
- Scaling out for increase data capacity, lower latency and performance.
- New type of data modelling like GRAPH.
While NoSQL generally means Not Only SQL, if you attend any of the NoSQL conferences, meetups, people more often mean
SQL. Recently, Michael Stonebraker made a point in SE Radio (http://www.se-radio.net/2013/12/episode-199-michael-stonebraker/) that most popular NoSQL databases like MongoDB and Cassandra have query languages very similar to SQL -- they're Not Yet SQL. While Hadoop when thru a phase of customer query languages, majority of vendors have SQL like interface to Hadoop.
In case of Informix, we started with SQL. Added flexible schema with the native support of JSON, MongoDB compatible query language (in fact, Informix NoSQL customers have to use the driver for MongoDB) and scale out via range and hash based sharding.
Once we added that, the question was, how would enterprises with TBs of data in relational form and hundreds of applications running on this data exploit the innovations in the API and the technology advantages.
When it comes to data and its infrastructure, evolutions seems to work much better than revolution.
Replicating the data from one form to another just won't work in most cases due to cost and consistency issues. So, we've added support for MongoDB APIs to access SQL data (relational data), features (joins, stored procedures, views) and enabled SQL to access JSON data.