Data Models: Relational, Document, Graph — What Are You Actually Choosing?

The first post covered what a data system should pursue (reliable, scalable, maintainable). This one goes a level down: what data model do you hold the data in? Relational, document, or graph — this choice isn’t small. It’s the underlying abstraction by which you map reality into data, and it decides how you model, how you query, even how you think about the problem.

Three data models

The real dividing line: one-to-many vs many-to-many

To choose between relational and document, the most practical ruler is to ask whether the data’s relationships are one-to-many or many-to-many. DDIA uses a résumé (a LinkedIn profile) as the example, and it’s vivid:

A related distinction on the side: document models are mostly schema-on-read (the structure is interpreted when the data is read, so writes are flexible), while relational is schema-on-write (the structure is checked at write time, like static typing). The first makes structural change easy, the second guarantees consistency — another “flexibility vs guarantee” trade-off with no absolute winner; it depends how often your data changes and how much consistency you need.

Why relational won back then, and why documents came back

There’s a fascinating piece of history hiding in this chapter. In the 1970s the relational model defeated the network and hierarchical models of the day, and the key wasn’t performance, it was being declarative: the network model made you hard-code in your program how to traverse step by step to the data (the access path), so a different query meant rewriting a pile of code; relational let you say only what you want and handed “how to get there” to the query optimizer. Sound familiar? It’s exactly the declarative theme I keep returning to in the SQL series — hand “how” to an engine that understands the data’s distribution better than you do.

And the document model is in a sense the hierarchical model resurrected (nesting, good locality, one read for the whole thing). It came back because a lot of modern data really is “one self-contained document” (a post, an order, an event), plus the appeal of schema flexibility. But note: what it resurrected is the hierarchical/nested structure, not an overturning of relational’s declarative victory — on many-to-many, relational and graph are still stronger.

Reflections

Choosing a data model is choosing how you want to think about the problem

I used to treat “which database” as a detail of technology selection; only later did I understand it’s a more fundamental decision: it frames how you map reality into data. Take the same business and think of it in tables, in documents, in graphs, and your mind walks completely different paths. So my order now is — look at the data’s shape first: is it tree-like (one-to-many, natural document boundaries)? Net-like (many-to-many, entities shared between each other)? Or is the relationship itself the point (social, recommendation, road networks)? Recognise the shape, then pick the model — rather than the reverse, forcing data into whatever trendy DB you wanted to use.

One-to-many vs many-to-many is my first question for “should this be a document DB?”

This ruler is too useful. Whether to adopt a document store like MongoDB, the first thing I ask is exactly that: does the data have natural document boundaries, are its relationships one-to-many (order + line items, post + comments, one person + several positions)? → Documents are a joy, reads and writes stay inside one unit, locality is good. But the moment a many-to-many shared entity appears (tags, authors, companies, products), the document model starts to hurt — either you copy entity data into every document (duplication, hard to update) or you store ids and join in the application layer yourself (moving the database’s job back into your code). When I see many-to-many, I seriously consider relational.

Relational’s victory was declarative’s victory — and that hasn’t been overturned

This bit of history hardened a belief for me: the decades-long direction of data tooling is continually taking “how” out of human hands and giving it to an engine. Relational beat the network model that way (you say what, the optimizer decides how), SQL’s EXPLAIN is that, Spark’s Catalyst is that. The document model brought back nesting and flexibility, a fine complement, but it didn’t and shouldn’t overturn that declarative core. So with any new data model or query language I first ask: does it let me focus more on intent, or does it drag me back into managing steps? Only the former is on the right side of history.