06-reference

practical data modeling database is not data model

2026-07-14·reference·source: Practical Data Modeling·by Joe Reis

"The Database Is Not the Data Model" — @joereis

Why this is in the vault

Reis cuts through a pervasive industry confusion that surfaces in nearly every enterprise data engagement: practitioners calling DDL files, dbt SQL, or reverse-engineered ERDs their "data model." This essay draws a clean line between representation (what things mean) and implementation (how they're stored), then traces the historical path that welded the two back together after Codd's original vision. The AI section is immediately actionable — agents see schemas, not tribal knowledge, which is exactly the failure mode that appears when clients expect LLMs to "just work" on their warehouses.

The core argument

Data modeling and schema design are related but distinct: schema design is the act of implementation, data modeling is the act of representation. The conflation has deep roots. Codd's 1970 relational model introduced data independence — logical up here, physical down there — but fifty years of practice welded the two back together. Chen's ER modeling (1976) was designed to "argue about reality before anyone wrote code," but gave way to DDL-first culture. ORMs reinforced it: Rails' app/models, Django's models.py, dbt's "models" (SELECT statements). Reis names the result "model blindness" — when a word means ERD, table definition, SQL transform, Python class, and multi-hundred-billion-parameter transformer all at once, it means nothing.

The correct flow: Reality → shared understanding → data model → schema design → database. Shorter: meaning → representation → implementation. A data model is instrument-agnostic — the same "customer" entity can live as normalized relational tables, a wide Iceberg table, JSON, Parquet in S3, or a graph node. Same song, different instruments.

The dangerous reversal: a single schema silently supporting multiple incompatible models. Three teams each get "technically correct" answers from the same customer table that cannot be reconciled — because nobody settled what "active customer" means across Marketing (logged in last 30 days), Finance (currently paying), Support (open account), and Product (completed onboarding). No one wrote a bug. Everyone wrote a different song off the same page.

The AI implication is sharp: an agent sees tables, columns, keys, and comments. It doesn't see the 2023 Slack thread that decided a canceled subscriber stays "active" for 90 days. It doesn't know that fct_orders double-counts refunds — a human filters those out automatically, forever, without writing it down. Semantic layers are useful, but most compensate for modeling decisions that were never made, paying permanent rent on a translation dictionary because meaning was never agreed upon.

"The bill always comes due" — consequences of skipping representation: brutal migrations (meaning is welded to physical structure, so moving off Postgres means re-deriving what the business means under deadline), integration archaeology (merging companies = translating between two missing dictionaries), governance theater (cataloging PII retention and lineage without defining what a customer is), AI underperformance (the model isn't confused; your data is), and naming bikeshedding (cust_id vs customer_id while nobody verifies whether the two tables mean the same thing).

The two questions: "What does this represent?" (data modeling) and "How should we implement it?" (schema design). Meaning must outlive structure — the understanding of a customer should survive four database migrations, two acquisitions, a re-platform, and whatever the stack looks like in 2032.

Mapping against Ray Data Co

When enterprise clients at phData surface their "data model" as a folder of dbt SQL or a Postgres ERD, this essay supplies the diagnostic frame. The confusion Reis names is the exact opening for a scoping conversation: the conceptual/logical layer is missing, and the client is already paying for it in integration pain, AI failures, or governance theater. The two-question test — "What does this represent?" and "How is it implemented?" — surfaces a gap between answers and turns it into a live opportunity.

The semantic layer argument is equally sharp in the modern data stack pitch. Most semantic layers (dbt Semantic Layer, AtScale, Cube) are compensating for absent data models, not extending good ones. That reframe shifts the conversation from tooling to architecture, which is where phData's value sits in a deal.

Related