With the rise of NoSQL data stores and their overwhelming popularity, the traditional databases started to lose the sheen. It is every IT decision-makers question of the hour - is it really the time for NoSQL?

For more than 25 years now, with our traditional SQL databases, we have been storing data that is structured and rigid in schema. We put a plan, design the data model and follow that thereafter. Any changes to that data model is not encouraged since it slowed down or even caused disaster in the database respectively.

But, the present world is more dynamic and the data that is produced by the web world is not rigid anymore. So, we need a solution to handle enormous data with an ever changing structure. The big brands, from whom we buy the SQL servers, use NoSQL DBs themselves to save a lot in their budget.

Building up and maintaining traditional databases is costly since it requires the experts (DBA). There was (and is) a gap between the database designer/administrator and the actual application developer. Filling this gap was a big challenge for the architects and product owners.

NoSQL has reduced the dependency on a DBA drastically, since maintenance costs are very low and making changes is so easy.

NoSQL data stores paved the way to storing unstructured data with high availability and scalability. Relational databases traditionally scale vertically, where more processors and memory is added to existing servers, involving huge cost and sometimes a downtime. Vertical scaling has a limit, and the system slows down when the data size is too huge to handle.

Therefore, horizontal scaling is a better option, i.e. adding more machines to the network to distribute the data over many machines. However horizontal scaling is available only in few of the relational databases, and is very expensive.

Horizontal scaling is the default norm of all the NoSQL databases (vertical scaling is optional). Since, the NoSQL databases are designed to work on commodity hardware, vertical scaling is not required. Hence, the cost is very low. High availability is provided by redundant replica of the data over a cluster.

So, we can store more and more data with lesser cost than before, and we can change the data model at our needs anytime, since there is no rigid schema. Maintenance is low, scaling out is easy and control is given to the application developers directly and not the DB Admin.

This scenario has encouraged many to start moving over to NoSQL completely. There are many open source, platform independent NoSQL options which are scalable and offer a rich API support for many languages.

Am I singing NoSQL’s praises too loudly? Yes there are some key points that doprevent enterprises from moving into NoSQL immediately.

NoSQL is not functional – Yes, the data is stored and retrieved at high speed, but the computation needs to be done by the machine which reads the data. For example, if I need the average marks of all the students. I need to fetch the marks of all the students and find the average. In contrast, if it is a relational DB, the database would do it for me. There are few exceptions in NoSQL like Solr/Elastic which do the aggregations for you. Other NoSQL databases use the Map-Reduce programming model for this purpose on distributed scale. But, these are not standardised yet!

Transactions are not easy -  NoSQL is not yet mature enough to provide ACID transactions similar to traditional relational databases.A few NoSQL databases such as Marklogic and Cassandra provide low-level simple transactions but not complex nested transactions. Enterprise scale complex transaction capabilities are yet to be built and standardised and this is the highest priority of NoSQL community now. The challenge is to provide consistency over transactions.

No standard language/tool - All relational databases follow the SQL standards. It is easy for developers to quickly build a cross-platform solution whereas in NoSQL, there is no such standard yet. The choice of tool/language is specific to the respective databases, and hence a strong team of developers with versatile skills over many programming languages is necessary.

So, should I pick NoSQL or SQL data store?

The correct answer is - It depends. If your application involves heavy complex transactions and reporting, then stickwith the NoSQL for now. In other cases, think about NoSQL as a potential alternative.

The above shortcomings are only temporary. NoSQL is going to completely change the perspective of how we store and manage big data. It might even change the way we do transactions and updates. Adapt early and master it, or you may be sorry later.

Vivek Karunanithi is Director of Engineering at Admatic IT services based in Chennai, India