NoSQL: A Family, Not One Thing

NoSQL (“not only SQL”) is a set of database families that depart from the relational model — each optimized for a specific access pattern. The trade is almost always the same: you give up the flexible relational join (and often strong consistency) to get a predictable, scalable access shape. Understanding the four families is how you stop reaching for “a database” and start reaching for the right one.

Key-Value Stores (Redis, Memcached)

The simplest model: a hash map — GET/SET/DEL by key.

• Strengths — absurdly fast, in-memory, great for caches, sessions, rate-limit counters, and hot-path lookups.
• Weaknesses — no querying beyond the key; data size limited by memory.

If your access is “look up one thing by its identifier, extremely often,” this is the shape you want. Redis adds data structures (sorted sets, streams, pub/sub) that make it the swiss-army-knife of operational infra — but it is a key store, not a query engine.

Document Stores (MongoDB)

Data lives in documents (JSON/BJSON) with a flexible schema. Related data is embedded, not joined:

{
  "user": "ada",
  "orders": [
    { "id": 1, "total": 9.99 },
    { "id": 2, "total": 19.99 }
  ]
}

• Strengths — natural fit for JSON-shaped domain data, no migration ceremony for schema drift, horizontal sharding is first-class.
• Weaknesses — joins are awkward (you embed or fetch separately), consistency is eventually/weaker by default.

Rule of thumb: if your data is naturally a tree/aggregate that you read whole (a profile with its settings, a post with its author summary), a document store fits. If you constantly query across aggregates, the relational model is better.

Column-Family Stores (Cassandra, HBase)

The closest mental model is a sparse table keyed by row key, with sorted columns per row — built for huge write volumes and wide rows over many nodes.

• Strengths — linear write scalability, tunable consistency (W/R quorums), no single leader bottleneck. Built on the LSM storage (see Storage Engines).
• Weaknesses — queries are driven by the primary key design: you model for your queries in advance (the “one table per query pattern” — CQL), and ad-hoc joins/aggregations are painful.

Cassandra is the “high-volume eventing / telemetry / time-series” engine: many writes, many nodes, reads by known keys or ranges.

Graph Databases (Neo4j, ArangoDB)

Data is nodes and edges, and the queries are about traversal: “shortest path,” “who is friends with whom at depth ≤ 3,” “which components touch this resource.”

• Strengths — traversal queries that would be nightmarish recursive SQL joins become natural and fast.
• Weaknesses — niche; you pay for the graph machinery unless relationship traversal is genuinely your core query shape.

Choosing: NoSQL vs SQL

Polyglot Persistence

Modern systems rarely use one database — they use the right one per concern in the same service: a relational store for the transactional core, Redis for caching/sessions, a column store for event ingestion, a document store for flexible product content. Polyglot persistence is not architecture for its own sake — it’s accepting that access pattern drives engine choice.

Practice Trajectory

1. For a shopping cart, a friend graph, a clickstream feed, and a login cache — name the right engine and justify it in one sentence each.
2. Model a blog in a document store (embed comments) and note where a relational design would have joined.
3. Design a Cassandra primary key so that “all sensor readings for device X in the last hour” is one efficient query.
4. Run a graph traversal (friends-of-friends) mentally in SQL vs in a graph query and count the complexity.
5. Write a “polyglot” architecture for a simple app and defend each engine choice against an interviewer.

When It’s the Right Tool