Databases•20 min read•Advanced
When to Reach for NoSQL
Document, key-value, wide-column, graph — what each is good at, and what it costs you.
'NoSQL' is a misleading umbrella for at least four different database families, each with its own niche. Picking the right one depends on your query patterns and scale.
Document stores (MongoDB, Couchbase)
- Store JSON-like documents instead of rows. Schema is flexible.
- Best for: data that's READ as one object (a user with their preferences, an order with its line items).
- Bad for: rich joins. You'll often denormalize.
Key-value (Redis, DynamoDB, etcd)
- Simplest model: blob keyed by string. O(1) reads.
- Best for: caching, sessions, leaderboards, distributed locks.
- Redis adds powerful in-memory structures: lists, sets, sorted sets, streams. Effectively a Swiss army knife.
Wide-column (Cassandra, ScyllaDB, HBase)
- Massive write throughput, linear horizontal scale.
- Best for: time-series, IoT, event logs at huge scale.
- You design the schema AROUND your queries — query patterns dictate primary keys.
Graph (Neo4j, ArangoDB)
- Nodes and relationships are first-class.
- Best for: social networks, fraud detection, recommendation, knowledge graphs — anywhere the answer requires traversing many hops.
💡 Tip
Most apps don't need NoSQL. They need an index, a cache, and a sane schema. Reach for NoSQL only when your access pattern truly doesn't fit a relational model.