When to choose NoSQL over SQL?

The agenda of this blog is simple. We’ll discuss various parameters that we keep in mind while deciding a perfect database for our Application Service.

In terms of data engineering, data pressure is the ability of the system to process the amount of data at a reasonable cost or a reasonable time. When one of those dimensions is broken, that’s a technology trigger and new inventions happen that result in new data technologies. In simple terms …

SQL is not obsolete, it’s just that now we have a different choice.

Before we jump up to comparing SQL and NoSQL databases, let’s take some time to appreciate the fact that SQL has been long into the industry (over 30+ years) and still has a good place in the modern application development environment.

Comparison Time … 🤞

1. SQL: Optimized for Storage
   NoSQL: Optimized for Compute/Querying
2. SQL: Normalized/relational
   NoSQL: Denormalised(Unnormalized)/Hierarchical
3. SQL: Table based data structure
   NoSQL: Depending on DBs, the data structures are …
   ★ Key-Values(DynamoDB, Redis, Voldemort)
   ★ Wide-column i.e. containers for rows(Cassandra, HBase)
   ★ Collection of Documents(MongoDB, CouchDB, DynamoDB)
   ★ Graph Structures(Neo4J, InfiniteGraph)
4. SQL: Ad hoc queries
   NoSQL: Instantiated views
5. SQL: Scale Vertically & Expensive. Can Scale Horizontally but challenging & time-consuming
   NoSQL: Scale Horizontally & Cheap
6. SQL: Fixed schema, altering requires modifying the whole database
   NoSQL: Schemas are dynamic
7. SQL: Good for OLAP
   NoSQL: Good for OLTP at scale
8. SQL: ACID(Atomicity, Consistency, Isolation, Durability) properties
   NoSQL: BASE(Basically Available, Soft state, Eventual consistency) properties

When to choose NoSQL? 👍

For our application service, when it comes down to:

✓ Well-known and well-understood types of access patterns

✓ Want simple queries

✓ Not much data calculation involved

✓ Have a common business process

✓ OLTP apps

If this is true, then NoSQL is a perfect Database and would be most efficient. We have to structure the data model specifically to support the given access pattern.

When NOT to choose NoSQL? 👎

If our application service has the requirements to support

✓ Ad-hoc queries. e.g. bi analytics use case or OLAP application

✓ May require “reshaping” the data

✓ Complex queries, inner joins, outer joins, etc.

✓ Complex value calculations

So in brief, for our application service, if we understand the access patterns very well, they’re repeatable, they’re consistent, and scalability is a big factor, then NoSQL is a perfect choice.

PS: Mature developers don’t use the word “flexible” for NoSQL databases. There is a difference in being dynamic and flexible. Data model design is an intelligent engineering exercise in NoSQL databases.

Thanks for reading this article! Add an 👏🏻 [clap] if you liked the comparison. Leave a comment below if you have any questions. Be sure to check my other Medium blogs and connect with me on LinkedIn for more interesting discussions.

Happy Coding <3