Data-model arguments become unproductive when they compare features without naming the workload. The useful question is not “Which database is best?” but “Which facts, queries, and failure modes should be cheap and explicit?”
Model one research dataset four ways
Suppose the system stores papers, researchers, topics, venues, and citations.
Relational
Tables and junction tables make keys, foreign keys, uniqueness, and multi-entity transactions explicit. This is a strong default for reporting and varied joins.
Document
A paper document can embed a bounded author snapshot and topic list so a paper page is one read. Independent researcher profiles and unbounded citations should usually remain referenced.
Graph
Nodes and relationships make citation paths, coauthor neighborhoods, and variable-depth traversals direct. Tabular aggregates and broad scans may be less natural.
Raw-data engine
CSV, JSON, or columnar files can be queried without first loading everything into a database. This shortens time to first query but shifts work into parsing, adaptive indexing, metadata, and repeated access.
In plain terms: every model makes one route feel like a hallway and another feel like climbing through a window. Choose the hallway used by the real workload.
Compare obligations, not slogans
| Question | Relational | Document | Graph | Raw data |
|---|---|---|---|---|
| Strong cross-entity constraints | Strong | More application work | Product-specific | External validation |
| Bounded aggregate read | Join or precompute | Natural embedding | Possible | Reparse or cache |
| Variable-depth relationships | Recursive query | Awkward | Natural | Custom processing |
| Ad hoc tabular analytics | Strong | Requires reshaping | Often secondary | Strong with analytic engines |
| First query before loading | Requires ingestion | Requires ingestion | Requires ingestion | Natural |
| Update ownership | Centralized schema | Aggregate-oriented | Relationship-oriented | File/pipeline-oriented |
Polyglot persistence has a bill
Using several databases can make each local workload elegant, but creates replication lag, failure handling, schema evolution, access control, observability, and on-call burden.
Before adding a second model, specify:
- Which system owns each fact?
- How does derived data catch up?
- What stale result is acceptable?
- How is a failed update replayed safely?
- Can the team operate the system at 3 a.m.?
A decision sequence
- Write the invariants and update boundaries.
- List the highest-volume and highest-latency reads.
- Identify unbounded growth and deep traversals.
- Choose the simplest model that makes the dominant paths natural.
- Prototype the hardest query with realistic data.
- Add another store only when measured limits justify its operational cost.
Review card
- Choose from workload and invariants, not category labels.
- Relational is strong for constraints, transactions, joins, and reporting.
- Document storage fits bounded aggregates read together.
- Graph storage fits relationship traversal.
- Raw-data querying trades loading delay for repeated parsing and indexing work.
- Every additional store creates consistency and operational obligations.