Topic 11.1
Choosing a Data Store: Key-Value, Document, Wide-Column, Graph, Search
In one line
Key-value stores answer get/put by key at massive scale; document stores keep whole aggregates together with flexible schemas; wide-column stores serve huge write-heavy datasets by partition key; graph databases traverse relationships; search engines rank free text. Start relational and add a specialised store when a measured access pattern needs it, keeping one source of truth.
Think of it like this
Tools in a workshop. A hammer, a saw and a drill each do one job superbly. A Swiss-army knife (a relational database) does most jobs well enough, which is why you carry it everywhere and fetch the specialist tool only when the job demands it.
Key ideas
- 01
Key-value (Redis, DynamoDB, etcd): O(1) access by key, no ad-hoc queries. Sessions, caches, carts, feature flags, rate limits, idempotency keys.
- 02
Document (MongoDB, Couchbase, Firestore): JSON-like documents; embed data read together; single-document atomicity (multi-document transactions exist but cost more). Catalogues with varied attributes, content, user profiles.
- 03
Wide-column (Cassandra, ScyllaDB, Bigtable, HBase): rows grouped by partition key and sorted by clustering columns; linear write scalability, multi-DC replication. Time-series, messaging history, IoT, activity feeds.
- 04
Graph (Neo4j, Neptune): nodes and edges with index-free adjacency; efficient multi-hop traversals (friends of friends, fraud rings, recommendations). A relational recursive CTE works for shallow graphs.
- 05
Search (Elasticsearch, OpenSearch): inverted indexes, relevance ranking, fuzzy matching, facets. Always a derived copy, never the source of truth.
- 06
Selection questions: what are the access patterns; do you need multi-entity transactions; ad-hoc queries; scale of writes and data; latency; consistency; operational skill and cost. PostgreSQL with JSONB, full-text and extensions covers more than people expect.
Code & diagrams
Interview problem
The problem
Pick stores for a ride-hailing platform
Components: rider and driver accounts, trips and payments, live driver locations (1M updates/min), trip history for 5 years, fraud detection over rider-driver-device-card links, and address search. Choose a store for each and name the source of truth.
When it breaks
Adopting a NoSQL store for an unplanned query workload
What you see
Analysts need joins and ad-hoc filters; every new question requires a new table or a full scan and a data pipeline.
Fix & prevent
Keep a relational source of truth or feed a warehouse via CDC; use NoSQL for the specific access patterns it was designed for.
Explain it without notes
When would you choose a document database over PostgreSQL?
Practice
For a URL shortener with 100K redirects/sec, choose the store for redirects and for analytics.
Trade-offs
- ↔
Specialised stores give performance for their pattern and cost you flexibility, consistency guarantees, and another system to operate.
Done when you can
I can map access patterns to store types and keep a single source of truth.