Modules / Database / NoSQL Lab

What are Non Relational Databases?

The same data, stored four different ways. Compare documents, key-value pairs, wide columns and graphs against the relational original — and see what each model makes easy and what it makes painful.

Typical query for “get Ada's orders”

Trade-offs

Non-Relational Databases: Four Different Bargains

"NoSQL" is not one thing. It is four families of database, each dropping a different relational guarantee to buy something else.

Quick Context

A non-relational database stores data in a shape other than fixed tables of rows and columns. The name "NoSQL" is a historical accident — it is best read as "not only SQL", since many of these systems now support SQL-like query languages.

The Four Families

Document (MongoDB, Couchbase) — self-contained JSON-like documents. Related data is embedded rather than joined, so one read returns everything.
Key–value (Redis, DynamoDB) — the simplest possible model: a key returns an opaque blob. Extremely fast, but you can only look things up by key.
Wide column (Cassandra, HBase) — rows keyed for distribution, where each row can hold different columns. Built for enormous write volume across many machines.
Graph (Neo4j) — nodes and edges as first-class citizens. Relationships are traversed directly instead of being recomputed by joins.

Schema Flexibility Cuts Both Ways

Press "Add field to one record" in each model. In a document store, one document simply gains a field — no migration, no downtime. In the relational model the same change is an ALTER TABLE affecting every row.

The catch: the database no longer guarantees that every record has the same shape, so your application must handle documents that lack the field. Schema enforcement did not disappear — responsibility for it moved into your code.

Denormalisation Is the Point — and the Cost

Document stores deliberately duplicate data so a page can be served with a single read. That is genuinely faster. But you have re-created the update anomaly from the relational lab: change a customer's name and you must now find every document that copied it.

The rule of thumb: relational optimises for correct writes, non-relational optimises for fast reads. Choose based on which one your workload does more of, and how much inconsistency you can tolerate.

Interactive Exploration Guide

Step through all five models and watch the "joins needed" counter. Relational needs two joins for Ada's orders; the document model needs none.
Look at the document view closely. The customer's city is repeated inside every order — that duplication is what buys the single-read speed.
Try the key–value model and read its trade-off note. There is no way to ask "which customers live in London" without scanning everything.
Add the field in relational, then in document. One is a table-wide migration; the other touches a single record.

Key Takeaway

There is no "better" model, only different bargains. Relational gives you enforced consistency and flexible ad-hoc queries; non-relational gives you speed, scale and schema freedom in exchange for moving integrity into your application. Most real systems today use both.

Cheat sheet