When to choose NoSQL over SQL or Relational Database? — by ombharatiya

For our app service, if we understand the access patterns very well, they’re repeatable, they’re consistent, and scalability matters ....

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