Data Models and Query Languages: Relational, Document, Graph, and Beyond

Data Models as Cognitive Frameworks

Most applications are built by layering data models: the application layer models the world as objects; those map to JSON documents, relational tables, or graph vertices; the storage engine represents those as B-tree pages or LSM segments; hardware represents those as electrical signals. Each layer hides complexity below via a clean abstraction. The key question at the application-to-storage boundary — which model to use — is the subject of this chapter. The critical insight: no model is universally superior. Each expresses certain query patterns naturally and makes others awkward.

The Relational Model: Dominant for Sixty Years

The relational model's durability comes from SQL being declarative: you specify the result pattern, and the query optimiser determines the execution strategy — which indexes to use, whether to parallelise, in which order to execute joins. This separation enables performance improvements without changing query syntax. The NoSQL movement introduced schema flexibility and new data models, but most NoSQL systems have since added joins, secondary indexes, and declarative query languages. Relational databases added JSON column types. The implementations are converging even as the conceptual models remain distinct.

Document Model: Locality and Schema Flexibility

The document model fits naturally when data has a tree structure of one-to-many relationships typically loaded as a unit. JSON has better data locality: all related data co-located, retrieved in one read. The relational technique of shredding a document into multiple tables introduces join overhead for queries that need the whole tree. Limitations surface at many-to-many relationships — document databases lack native join support (or have limited syntax like MongoDB's $lookup), and absence of foreign key constraints means consistency must be managed in application code.

Normalisation vs Denormalisation

The normalisation/denormalisation axis is the central read-write performance trade-off in data modelling. Normalised data — each fact stored once, referenced by ID — is faster to write, consistent by construction, but requires joins on every read. Denormalised data co-locates copies for fast reads but creates consistency obligations: when the original changes, all copies must be updated atomically or the system becomes inconsistent. The Twitter timeline case study is instructive: the precomputed fan-out (denormalised) avoids expensive join-on-read at 2M reads/sec, but post content and like counts are deliberately kept normalised because they mutate too frequently for duplication to be practical.

Graph Models: When Many-to-Many Is the Whole Point

When many-to-many relationships are pervasive and connections carry semantic meaning, the property graph model is the natural fit. In the labeled property graph model, each vertex has a unique ID, a label, and a jsonb property map; each edge has a tail vertex, head vertex, a relationship label, and its own properties. Two indexes on tail_vertex and head_vertex enable efficient bidirectional traversal. The edges table is the many-to-many join table from relational theory, generalised to support heterogeneous relationship types in a single structure.

MATCH
  (person) -[:BORN_IN]->  () -[:WITHIN*0..]-> (:Location {name:'United States'})
  (person) -[:LIVES_IN]-> () -[:WITHIN*0..]-> (:Location {name:'Europe'})
RETURN person.name

Query Languages: Declarative vs Imperative

Declarative languages expose only the result specification to the query optimiser, which can exploit indexes, choose join algorithms, and parallelise execution freely without any changes to the query. Imperative traversal code fixes the execution strategy at write time. The performance gap is significant at scale.

Event Sourcing and CQRS: Writing Facts, Deriving State

Event sourcing stores every state change as an immutable, append-only event. Current state is derived by processing the event log sequentially. CQRS (Command Query Responsibility Segregation) separates the write path (event log) from the read path (materialised views), allowing each to be optimised independently. A command is validated first; only if valid does it become a fact appended to the log — the log contains only valid events, and consumers cannot reject events. Events are named in the past tense (booking_payment_confirmed, not confirm_booking) because they record completed facts.

Choosing Your Data Model

Model selection should be driven by the dominant relationship structure in your data and the query patterns that matter most. These models are not mutually exclusive — PostgreSQL's jsonb, recursive CTEs, and event log tables can coexist in the same database. Knowing what each model optimises for is what lets you use that convergence intentionally.

Mental Models