Relational databases have been our trusty companions for decades and still they are. But in today’s fast-paced, high-volume, globally distributed world, sometimes we need something different. That’s where NoSQL databases step in.
But wait — NoSQL or Not only SQL isn’t just one thing. There are four main types, each designed for different kinds of problems. Think of it like choosing a vehicle: you wouldn’t use a CNG auto-rickshaw to carry a refrigerator, right!?
So, let’s skip the textbook jargon and explore which NoSQL database to use, when, and why, using real-world scenarios.
1. Document based NoSQL Databases
Think of a document-based NoSQL database as a filing cabinet.
Inside this cabinet, you’ll find multiple files (called collections). Each file holds several papers (called documents) — and each paper contains all the information related to one entity.
Let’s say there’s a file named “Student-Profile-Class-VI-2020”. This file stores documents representing each student’s profile from Class VI in 2020. Now here’s the cool part:
There’s no rigid format required. One document might contain a photo, another might not, one document might have guardian info, another might not. The structure can vary, and that’s completely fine — as long as the key identifiers (like student ID or name) are there.
That’s exactly how document databases work: each document is flexible, self-contained, and schema-less.
When to Use:
- You need flexibility. Fields can differ from one document to another.
- You work with hierarchical or semi-structured data.
- Speed matters more than strict schema rules.
Scenario:
You’re building an e-commerce app. Each product can have different attributes — shoes have sizes, laptops have RAM and storage, T-shirts have colors. Trying to cram this into rows and columns would be a nightmare.
So, go with a document based DB — each product gets its own schema-less document, fits perfectly to its type.
2. Key-Value based NoSQL Databases
A key-value database can be thought of as a digital version of a locker system at a grocery shop or a hostel or a bank.
Each locker has a unique number (key), and inside it is your item (value). You don’t care how it’s arranged inside — you just need to know which locker to open. Simple, fast, and direct.
And, what’s inside the value? It could be anything — a string, a number, a JSON blob, or even a file. The system doesn’t care. It just stores and retrieves it as-is — like putting any item inside your locker: a book, a bag, a lunchbox or a gold bar!
When to Use:
- You need super-fast access to data using a known key
- Your data is simple and flat
- You don’t need filtering or search — just quick lookup
- You’re building features like caching, session storage, or simple state tracking
Scenario:
Imagine you’re running a digital token system in a hospital.
- Each patient at the front desk is given a token number like token_104
- When their turn comes, the system checks the token to retrieve: Name, Doctor’s name, Appointment time
All this is stored in a key-value pair like:
Key: token_104
Value: { "name": "Mukitul", "doctor": "Dr. Islam", "time": "10:45 AM" }
So, if you keep this in a key-value based database, then there’s no need to scan a table or filter thousands of records — just hit the key and get the value.
Fast, simple, and perfect for real-time systems.
3. Column based NoSQL Databases
Column-based NoSQL databases flip the way we think about storing data. Instead of keeping rows together like traditional databases, they group data by columns — making them extremely efficient for analytical queries or handling large datasets.
Now, this type actually has two flavors:
3A. Column-Oriented Databases
Now, imagine a giant attendance sheet where each row is a student, and each column represents a specific day (Day 1, Day 2, Day 3…).
If you’re trying to find out who was present on Day 3, would you read all rows with every student’s name, class, and attendance for other days? Nope. A column-oriented database stores all values for “Day 3” together — so you can scan that single column directly without touching unrelated data.
This layout is perfect for analytical workloads, where queries often aggregate or filter by just a few fields out of many.
When to Use:
- Analytics, dashboards, data warehouses
Online Analytical Processing (OLAP) systems (heavy read, light write)
3B. Column Family Databases
Think of it like organizing a shelf, but instead of putting books (rows) side-by-side, you’re grouping similar topics (columns) into labeled boxes (column families).
Each row in a column family can have its own set of columns — and it doesn’t have to match others. This makes it great for storing semi-structured or evolving data.
In the real programming world, let’s say you’re storing user activity logs. Some users may have “login_time”, others may have “purchase_history” or “last_location”. Instead of storing this into a fixed table, you can store each user’s data as a flexible row with only relevant columns.
When to Use:
- Real-time dashboards
- Massive write-heavy applications
To know more about these two types you may read this article of Daniel Abadi’s Distinguishing Two Major Types of Column-Stores
Scenario:
Let’s say you’re building a ride-sharing app. Every user (rider or driver) has different activity logs: trip history, payments, preferences. Using a column family DB, each user gets their own row, and you can attach columns like trip_1, trip_2, payment_method, etc., as needed — without enforcing a fixed schema.
4. Graph based NoSQL Databases
Picture a giant map of social connections — like Facebook’s friend network. Each person is a node, and every relationship (friend, follow, block, like) is a link (called an edge).
Now imagine asking: “Who are the mutual friends of Ratul and Mukit?”
Graph databases are built exactly for this. They store data as nodes and edges, making relationships first-class citizens. Instead of crawling through foreign keys and joins, graph databases traverse connections directly — like hopping from one friend to the next.
When to Use:
- Social networks
- Fraud detection
- Recommendation engines
- Network topology maps
Scenario:
Let’s say you’re building a movie recommendation system. Each user watches certain movies, gives ratings, and follows friends. A graph database can quickly answer: “What movies did my friends love that I haven’t watched yet?” And just like that, it pulls the data by walking the graph — no heavy JOINs, no performance dip.
Conclusion
NoSQL doesn’t mean “no structure” — it means flexible structure. The key to choosing the right type is understanding your data and your access patterns.
So next time you’re starting a project, don’t just default to “MongoDB because it’s popular,” or “Cassandra because I know it very well.” Instead, ask: “What does my data look like? How will it be used?” The answer will point you to the right kind of NoSQL.
Last but not the least, here are some popular NoSQL databases –
NoSQL Database Type | Popular NoSQL Databases | |
Document based | MongoDB, Couchbase, Amazon DynamoDB | |
Key-Value based | Redis, Amazon DynamoDB | |
Column based | Column-family | Apache Cassandra, ScyllaDB, HBase |
Column-oriented | Google BigQuery, Amazon Redshift | |
Graph based | Neo4j, Amazon Neptune | |
