Types of NoSQL Databases — Document, Key-Value, Graph, Column
Fast recall
Quick revision
Core answer
Awareness that NoSQL is not a single technology but a category of different database types with distinct use cases
Thinking NoSQL means only MongoDB and not knowing about key-value, wide-column, or graph databases
Match each NoSQL type to a concrete use case from your experience or common industry patterns, explaining why that type fits the access pattern
Interview-ready guide
Interview answer
NoSQL names several database families rather than one technology. Document stores such as MongoDB hold BSON documents and can validate their shape. Key-value products start with key-based access, but Redis adds structures such as hashes, sets, sorted sets, and streams, while DynamoDB adds secondary indexes. Wide-column systems such as Cassandra design tables around partition and clustering keys. Graph systems such as Neo4j make relationships first-class for traversal. The label alone does not guarantee speed or scale. Choose from the actual keys, queries, updates, transaction scope, partition behavior, and failure requirements, then test the named product with representative data.
Types of NoSQL Databases — Document, Key-Value, Graph, Column
Direct Answer
Four common NoSQL families are document, key-value, wide-column, and graph databases. The labels can overlap and do not guarantee one performance or consistency model. Compare named products by the keys, queries, updates, transaction scope, and distribution behavior the application needs.
Code Example
Document store
Key: product P123
Value: one BSON document with name and nested attributes
Key-value store
Key: session:12345
Value: serialized session with an expiry
Wide-column store
Partition key: device_id
Clustering key: recorded_at
Query: readings for one device in a time range
Graph store
Pattern: (user)-[:FOLLOWS]->(friend)-[:LIKES]->(product)
These are access-pattern sketches, not interchangeable client APIs. Each real implementation needs the product's supported schema, query, consistency, and transaction rules.
Common Mistakes & Pitfalls
- Treating every product as its label: Redis has rich structures and optional search capabilities; DynamoDB supports key-value and document items plus secondary indexes.
- Using benchmark slogans: A fixed “10x” or “millions per second” claim has no meaning without data model, hardware, cluster, durability, and query details.
- Ignoring key design: Cassandra and DynamoDB performance depends heavily on partition-key distribution and supported query paths.
Check your understanding
Answer these without looking back at the article.
- When would you use Redis vs a relational database for caching?
- What is MongoDB's document model?
- Why is Cassandra good for time-series data?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.