Which data store type fits the workload (relational vs document vs key-value vs graph vs time-series)
Verdict: Match the workload's data shape to the store. Multi-table records needing ACID transactions go relational; variable per-record JSON goes document; simple id lookups go key-value; multi-hop relationships go graph; high-ingest timestamped metrics go time-series.
| Criterion | Relational | Document | Key-value | Graph | Time-series |
|---|---|---|---|---|---|
| Data shape | Normalised tables referencing each other by primary key | JSON documents with per-record schema flexibility | A unique key paired with an opaque value | Entities as nodes joined by links defining relationships | Values organised by time, ingested at high volume |
| Best for | Financial ledgers and billing needing strict multi-table transactions | Product catalogues and profiles where fields vary per record | Caching, sessions, and feature-flag lookups by a simple id | Multi-hop traversals such as social networks or fraud rings | Sensor and metric streams needing near real-time time-window aggregation |
Rules
- Relational stores enforce integrity and support ACID transactions and joins across related tables, matching financial ledger and billing workloads.
- Relational databases assign each entity instance a primary key that other tables reference, which normalises data so a value like a customer is stored only once.
- A document database is a specific form of key-value store whose value is a JSON document the engine is optimised to parse and query.
- Key-value stores are valued for low latency and simplicity, listing caching, sessions, feature flags, and recommendation lookups among their workloads.
- Graph stores are built for relationship-first querying and variable-depth traversals, explicitly listing social networks and fraud rings as workloads.
- Time-series stores manage values organised by time and are optimised to ingest and analyse large volumes in near real time with time-window queries.
Traps
- Key-value stores support simple lookups by key, not traversal across connected entities - don't pick key-value for relationship or fraud-ring queries.
- Document stores offer flexible schemas but only selective transactional scope, not the strict multi-entity transactions a financial ledger requires.
- Graph stores suit relationship traversals, not simple low-latency single-identifier lookups - don't pick graph for caching or session state.
- A relational database applies a fixed table-and-key schema, a poor fit for records that vary attribute by attribute and are naturally expressed as JSON documents.