11 — NoSQL Stores: Key-Value, Document, Wide-Column, and Graph

"Not SQL, so probably MongoDB" was my NoSQL model, and it lumped four different data models into one blob. Writing them down gave each family a distinct job: the four NoSQL families — key-value, document, wide-column, and graph — each optimize for a different shape of data and access pattern, and the choice between them is driven by the data's structure and how you query it. [1][2] "NoSQL" is not one thing; it is four distinct data models, and picking the wrong one quietly caps the system's performance.

The framing that landed is to classify each family by the question it answers best. Key-value answers "what is the value for this exact key?" Document answers "give me this whole object, with all its nested fields." Wide-column answers "give me a range of keys, fast, at enormous scale, with sparse data." Graph answers "what is connected to what, and how many hops between them?" [1][2]

The four families

• Key-value store. Generally allows O(1) reads and writes — a lookup takes about the same time no matter how many items are stored — and is often backed by memory or SSD. Keys can be maintained in sorted order for efficient range retrieval. High performance, ideal for simple data models or rapidly-changing data like an in-memory cache [1]. The trade-off: only a limited set of operations is offered, so any additional query complexity is pushed to the application layer.
• Document store. Centered on documents (JSON, XML, binary) where each document holds all the information for a given object. Documents can have completely different fields from one another, and they are organized by collections, tags, metadata, or directories. The store provides an API or query language that queries by the document's internal structure [2]. Good for self-contained objects with evolving schemas.
• Wide-column store. The basic unit is a column (a name/value pair). Columns group into column families (analogous to a SQL table), and super column families further group them. Each value carries a timestamp for versioning and conflict resolution. You access columns by row key, and keys are kept in sorted order for efficient selective range retrieval [3]. Google's Bigtable was the first; HBase and Cassandra followed. Optimized for massive scale with sparse data.
• Graph database. Each node is a record and each arc is a relationship between two nodes. Optimized to represent complex relationships — many foreign keys, many-to-many — with high performance for data models where the _connections_ are the point, like a social network [4]. Relatively new, with a smaller tooling ecosystem; some are accessed only via REST.

How I choose

The decision is driven by two questions: what is the shape of one record, and how do I query it? If a record is a flat blob I look up by an exact key, key-value is the right shape and the fastest option. If a record is a rich, self-contained object with nested fields that evolve independently, document is the fit. If the data is enormous, sparse, and I need range scans across keys, wide-column is built for exactly that. If the relationships between records are themselves the query ("friends of friends," "shortest path," "who influences whom"), graph is the only family that answers those queries without catastrophic joins.

The mistake I try to avoid is reaching for a document store for _everything_ because it is the most familiar NoSQL flavor. A document store used as a poor man's key-value is overkill; a document store asked to traverse relationships becomes a slow join engine. Each family has a shape it was designed for, and staying inside that shape is what keeps the system fast as it grows.

How I use this

When I model a new dataset, I name its shape out loud first — flat lookup, nested object, sparse-at-scale, or relationship-heavy — and that name points at a family before I think about specific products. For caches and session state, key-value (Redis). For content with evolving schemas (blog posts, product catalogs), document. For write-heavy time-series or enormous sparse datasets (event logs, user-activity feeds at scale), wide-column. For anything where "who is connected to whom" is the core query (recommendations, social graphs), graph. The discipline of naming the shape stops me from defaulting to the one NoSQL product I happen to know.

References

[1] "Key–value database," Wikipedia. [Online]. Available: https://en.wikipedia.org/wiki/Key%E2%80%93value_database

[2] "Document-oriented database," Wikipedia. [Online]. Available: https://en.wikipedia.org/wiki/Document-oriented_database

[3] F. Chang et al., "Bigtable: a distributed storage system for structured data," 2006. [Online]. Available: https://www.read.seas.harvard.edu/~kohler/class/cs239-w08/chang06bigtable.pdf

[4] "Graph database," Wikipedia. [Online]. Available: https://en.wikipedia.org/wiki/Graph_database

[5] "Introduction to NoSQL," YouTube, 2019. [Video]. Available: https://www.youtube.com/watch?v=qI_g07C_Q5I