Press enter to see results or esc to cancel.

NoSQL – revolution or overdose?

Reading Time: 2 minutes

What is it like to drive a left-handed car if all you have ever driven is a right-handed car? Confusing!

What is it like to develop on a NoSQL db if all you have ever done is a relational databases? Embarrassing!

Embarrassing? Exactly!

Somehow, we are all brainwashed into worshiping normalization in our academics and career until recently. We spent our 20’s learning and applying the various normalization forms. Left join, right join, and outer joins were considered the Holy grails of our times.

It felt superstitious explaining a rookie dev why normalization was applied to our db.

It felt counter-intuitive to divide our data among so many tables, and write complex join queries to get them back.

It felt unnecessary to add indexes to optimize query performance.

Relational databases are ideal for transactional data. They are normalized to avoid duplication. Recurring data is subdivided between multiple tables. To query, we have to join all the required tables.

However, as the data grows the accessing data though joins become complex. Rigid schema design demands up-front expertise. Queries response slows down because of multiple joins — demanding frequent re-indexing.

Why go the NoSQL way?

Simple storage:

NoSQL is very well suited for persistence storage and occasional querying. If your data is not simultaneously accessed and updated by multiple users — then NoSQL could be your best choice for database.

Schema less:

This means less maintenance overhead when adding new columns. As and when new columns are required, just start adding new fields. Use the new fields for new data. Querying is easy, as absent fields are not included in queries.

Scale cheap:

It is cheaper, and easier to keep adding more machines as data grows. We do not need powerful machines to support more data unlike relational database. By distributing documents between partitions we can achieve the same scaling as scaling up. We can partition data based on fields, and accordingly access data.


It is very intuitive to maintain code bases when the data modeled around business objects. Our DTOs could model real world objects. This erases data querying complexity. Every document contains the self sufficient categorial information in one place. No need to reference check for master-child tables for values. Hence easy querying.

Getting started with NoSQL.

The best way to learn is to unlearn all of your relational database skills. Starting from scratch, opens up new grounds. Establishes different perspectives. Revitalizes creative juices.


Leave a Comment

Leave a Reply