What are the main NoSQL data models, with an example database for each?

Document stores — MongoDB, Couchbase, Firestore

Store self-contained, semi-structured documents (typically JSON/BSON), where related data is often embedded directly in one document rather than normalized across tables.

{
  "_id": "user_123",
  "name": "Alice",
  "addresses": [
    {"type": "home", "city": "Austin"},
    {"type": "work", "city": "Dallas"}
  ]
}

Best fit: content with variable/nested structure per record, rapid schema iteration, read patterns that naturally want "the whole object" in one fetch.

Key-value stores — Redis, DynamoDB, Memcached

The simplest model: a unique key maps to an opaque value (string, blob, or a richer structure in Redis's case — lists, sets, hashes). No querying by value content in the basic model. You fetch by key, full stop.

SET session:abc123 '{"user_id": 42, "expires": "2026-07-05T00:00:00Z"}'
GET session:abc123

Best fit: caching, session storage, feature flags, rate limiting — anything with simple, extremely high-throughput lookups by a known key.

Wide-column stores — Cassandra, HBase, Google Bigtable

Rows can have a different, sparse set of columns, and columns are grouped into "column families" stored together on disk. This is optimized for very high write throughput and horizontal scale across many nodes, with each row addressable by a partition key.

Row key: user_123
  Column family "profile":   name=Alice, email=alice@example.com
  Column family "activity":  last_login=2026-07-01, login_count=57

Best fit: time-series data, IoT sensor readings, massive-scale write-heavy workloads (Cassandra was originally built at Facebook for exactly this kind of scale).

Graph databases — Neo4j, Amazon Neptune, ArangoDB

Model data explicitly as nodes (entities) and edges (relationships), with relationships as first-class citizens that can themselves carry properties. This is optimized for traversing and querying connections, not just individual records.

MATCH (a:Person {name: 'Alice'})-[:FOLLOWS]->(b:Person)-[:FOLLOWS]->(c:Person)
WHERE NOT (a)-[:FOLLOWS]->(c)
RETURN c AS suggested_follow

Best fit: social networks, recommendation engines, fraud detection (tracing chains of connected transactions), and any domain where "how are these things related, possibly several hops deep" is the core query pattern — a relationship a relational database would need several expensive joins (or a recursive CTE) to express.

Choosing between them

The decision should follow from your actual query patterns: "I always fetch this whole record together" points to document; "I only ever look things up by a single known key" points to key-value; "I write enormous volumes of data that rarely needs complex ad-hoc querying" points to wide-column; "my core question is about relationships/paths between entities" points to graph. Defaulting to relational and only reaching for one of these when the data shape or scale genuinely demands it is usually the right instinct.