NoSQL vs Relational Databases: When to Use What

Relational databases have existed for more than 40 years now, and they work well. There are specific use cases, however, where a software professional might use a NoSQL database over a relational one. Some of those reasons are:

• Relational databases are highly available and highly consistent. Thereby running atomic operations on them is a piece of cake and they run very well (i.e. database transactions run very well on relational databases). Hence, if you are looking for normal CRUD operation type websites, a relational database is still a solid option to choose.
• CAP theorem stands for C – Consistency, A — Availability, P — Partitioning (or Scalability) and states that having all three properties at the same time is not possible, so at the best, you can get two properties from these and not the third one. Relational databases provide consistency and availability but lack solid partitioning functionality, even though relational databases support partitioning, but due to the core concept of ‘Joins’ and other things like shared indexes, scaling them using partitions is very difficult and not optimal.
• The point mentioned above is the key reason for the existence of NoSQL databases like MongoDB or Cassandra. These databases provide excellent support for horizontal scalability. They do lack a bit on the principle of consistency as most of them don't support distributed transactions (or as perfectly as a relational database does). They also don't have joins exactly like relational databases, and these are the key reasons why they scale so well horizontally (i.e. by adding more machines horizontally).
• Another reason for the usage of NoSQL databases is their developer friendliness. DB’s like MongoDB are document databases where the data is stored as a JSON, which is highly compatible with most web user interfaces (read ‘Single page Java Apps’) and has excellent tooling support.
• Relational databases have a strict schema for the data storage. Through the use of 'alter' statements, the schema can be changed, but it has its impact on the existing code ('application specific code'), which has to be changed in accordance with the changes made to the schema. The NoSQL databases, on the other hand, support easy schema changes on the fly without affecting any existing code.

How Do NoSQL Databases Scale Horizontally?

There are 2 key approaches:

1. Auto-Sharding: This is what is followed by Google's Bigtable. It basically assigns a range of values to a partition (this is one approach for partitioning). So when a certain value falls within a certain range, the database knows which partition to look in. It is somewhat similar to a hashtable bucketing concept.
2. Consistent Hashing: The other approach is consistent hashing, which is followed by DynamoDB in Amazon. It prepares a hash of machines in a circular fashion, and if a certain machine fails in the circle, the database knows where to look for the next record in this circle of machines.