Free sample lesson · NoSQL Database Selection: Redis, DynamoDB, MongoDB, and Cassandra

Why 'NoSQL' is misleading: four completely different data models

Lesson 1 of the Wondering course NoSQL Database Selection: Redis, DynamoDB, MongoDB, and Cassandra

NoSQL Names What It Is Not

The label NoSQL tells you almost nothing useful.

It groups databases by what they lack, a fixed relational schema and SQL, rather than by what they actually do.

Under that one umbrella sit at least four different data models: key-value, document, wide-column, and in-memory.

Redis, DynamoDB, MongoDB, and Cassandra all wear the NoSQL badge. They solve fundamentally different problems.

One label, four models
  • NoSQL: A label defined by what it lacks, not what it does.
  • Key-value: Example: DynamoDB.
  • Document: Example: MongoDB.
  • Wide-column: Example: Cassandra.
  • In-memory: Example: Redis.

Treating them as interchangeable is one of the most common mistakes engineers make when picking storage.

Key-Value and Document

A key-value store is the simplest shape. You hand it a key, it hands back a value, and it does not care what is inside that value.

DynamoDB is the familiar example. Predictable lookups at scale are the point.

A document store goes further. It understands the structure inside the record, so you can query fields within it.

MongoDB is the familiar example here. You trade some simplicity for the ability to ask richer questions of nested data.

Key-value vs document
  • Key-value
  • Document

Wide-Column and In-Memory

Wide-column stores organize data into rows whose columns can differ from row to row.

Cassandra is the familiar example. It is built for writing and reading enormous volumes across many machines.

In-memory stores keep data in RAM rather than on disk.

Redis is the familiar example. Speed is the whole reason it exists, and durability is a secondary concern.

These two are not competitors. One is about scale of storage, the other about speed of access.

Different problems, same label
  • Cassandra
  • Redis

Why Conflating Them Hurts

Say a team decides to "move to NoSQL". That sentence contains no decision at all.

Choosing Redis because a benchmark praised MongoDB is choosing a cache when the need was a queryable document store.

Choosing Cassandra because DynamoDB scaled well elsewhere is choosing a different model with different query rules.

The label hides the choice. The data model is the choice.

Can a label make you decide worse?

Ask the Model, Not the Label

The practical habit is small. Stop saying NoSQL and name the model instead.

Ask what shape the data has, what the queries look like, and whether speed or scale is the pressure.

Then the four models sort themselves: key-value for plain lookups, document for queryable structure, wide-column for huge distributed volumes, in-memory for raw speed.

Redis, DynamoDB, MongoDB and Cassandra stop being rivals once you see them as answers to four different questions.

Four models, four questions

Check yourself

Does the label NoSQL identify one specific data model?

  • No
  • Yes

Answer: No

Correct. NoSQL is an umbrella label for several different data models, not one specific model. It mainly indicates the absence of a fixed relational schema and SQL.

A store that returns a value without examining its contents is _____; one that queries fields inside records is _____; rows with differing columns describe _____; data kept in RAM for speed is _____.

Answer: A store that returns a value without examining its contents is key-value; one that queries fields inside records is document; rows with differing columns describe wide-column; data kept in RAM for speed is in-memory.

A key-value store returns a value for a key without caring about the value's internal contents. A document store understands record structure and can query fields inside it. Wide-column stores support rows with varying columns, while in-memory stores keep data in RAM for speed.

Which pairing correctly matches each database with its data model?

  • DynamoDB—key-value; MongoDB—document; Cassandra—wide-column; Redis—in-memory
  • DynamoDB—document; MongoDB—key-value; Cassandra—in-memory; Redis—wide-column
  • DynamoDB—wide-column; MongoDB—in-memory; Cassandra—document; Redis—key-value
  • DynamoDB—in-memory; MongoDB—wide-column; Cassandra—key-value; Redis—document

Answer: DynamoDB—key-value; MongoDB—document; Cassandra—wide-column; Redis—in-memory

DynamoDB is the example associated with key-value storage, MongoDB with document storage, Cassandra with wide-column storage, and Redis with in-memory storage.

Keep going

This is lesson 1 of 8 in NoSQL Database Selection: Redis, DynamoDB, MongoDB, and Cassandra. Next up:

  1. Access patterns: the real constraint to optimize for
  2. Redis: in-memory typed structures for sub-millisecond latency
  3. DynamoDB: managed key-value at scale with access pattern design
  4. MongoDB: flexible document queries and schema evolution
  5. Cassandra: distributed write throughput and time-series workloads

Start this course free

Wondering turns any topic into short lessons you can read, watch, or listen to, with practice questions and an AI tutor.