NoSQL · Data models beyond tables
What are the main types of NoSQL databases?
Short answer
The main families are document, key-value, wide-column and graph stores. Search engines and vector databases are also non-relational, but they optimise for text relevance or similarity rather than record storage.
The data model determines the queries a store is good at. Choosing the wrong family is more expensive than choosing the wrong brand, because the access pattern is baked into the storage layout.
The four classic families
- Document: JSON-like documents with nested fields. Examples include MongoDB and CouchDB. Good for aggregates and flexible attributes.
- Key-value: an opaque value addressed by a key. Examples include Redis, DynamoDB and etcd. Good for sessions, caches and simple lookups.
- Wide-column: rows grouped by partition key with sorted columns. Examples include Cassandra, HBase and Bigtable. Good for high write volume and time-series style access.
- Graph: nodes and relationships stored as first-class entities. Examples include Neo4j and Amazon Neptune. Good for traversals and relationship-heavy queries.
Search engines such as OpenSearch and vector databases such as pgvector or Milvus are sometimes grouped with NoSQL. They specialise in inverted indexes or approximate nearest-neighbour search, and they usually sit beside a system of record rather than replacing it.
Document: { "_id": 1, "name": "Asha", "orders": [10, 11] }
Key-value: session:abc123 -> {"userId": 7, "expires": 1767225600}
Wide-column: partition "user_7" -> row "2026-10-01" -> {"clicks": 12}
Graph: (Asha)-[:PLACED]->(Order 10)Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1Which family would you use for a social graph and why?
- 2When is a wide-column store better than a document store?
- 3Where do search engines fit in this taxonomy?
- 4Can one database belong to more than one family?
Say it in the interview
I group NoSQL into document, key-value, wide-column and graph stores, because the data model drives the query model. Document stores suit aggregates, key-value stores suit simple lookups and caching, wide-column stores suit high-volume partitioned writes, and graph stores suit relationship traversals. Search and vector databases are adjacent categories that usually complement a system of record. In practice I evaluate the actual consistency and query behaviour, since many products blur the labels.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live NoSQL mock interview and get scored feedback on depth, clarity and confidence.