NoSQL Database Types

Overview

NoSQL databases fall into four broad categories - key-value, document, wide-column, and graph - each optimized for a different data shape and access pattern. Matching a category to a workload is far more useful in an interview than memorizing product names.

🧠 Mental model: Key-value = a dictionary (look up by word). Document = a folder of papers (each paper is different). Wide-column = a spreadsheet where each row can have different columns. Graph = a social network map (nodes and connections).

Key Concepts

Before reaching for these, know when to leave the relational world at all - see SQL vs NoSQL. The four canonical categories compare as follows:

Category	Data model	Typical access	Example stores
Key-value	Opaque value addressed by a unique key	Get/put by key	Redis, DynamoDB
Document	Self-describing JSON-like documents	Query by key or by fields	MongoDB, Couchbase
Wide-column	Rows grouped into dynamic column families	Query by partition + clustering key	Cassandra, HBase
Graph	Nodes and edges carrying properties	Traverse relationships	Neo4j, Neptune

Key-value is the simplest model: the store treats the value as opaque bytes and offers blisteringly fast lookups by key, ideal for caches and sessions.
Document stores understand the structure inside each record, so you can index and query on nested fields while still varying the shape per document.
Wide-column stores organize data by a partition key that decides placement and clustering keys that sort rows within a partition, which suits huge, write-heavy, query-by-key workloads.
Graph stores make relationships first-class, so multi-hop traversals (friends-of-friends, recommendations) stay cheap instead of exploding into recursive joins.

Key-value and wide-column stores commonly distribute data across nodes using Consistent Hashing, which spreads keys evenly and limits how many keys move when the cluster grows or shrinks.

Trade-offs

Simpler models scale and perform more predictably but answer fewer question shapes: a key-value store is fast yet blind to what it stores, so you cannot query by value. Richer models buy query power at a cost - graph traversals are expensive to shard, and document stores tempt you into unbounded nesting. The skill is choosing the least powerful model that still serves your access pattern.

Interview Tips

Lead with the access pattern, then name the category, then a representative product.
If asked "why not the others?", contrast against the access pattern rather than listing features.
Mention that a single system often uses several categories for different subsystems.

Summary

NoSQL splits into four categories: key-value, document, wide-column, and graph.
Key-value is fastest but opaque; document adds field-level queries.
Wide-column targets massive write-heavy, key-based workloads; graph targets relationship traversal.
Many stores distribute keys with consistent hashing to scale horizontally.
Choose the least powerful model that still satisfies the access pattern.