The Database Is Not the Data Model - by Joe Reis

Practical Data Modeling

SubscribeSign in

The Database Is Not the Data Model<br>Representation vs Implementation

Joe Reis<br>Jul 14, 2026

96

Share

In discussions with data practitioners, I keep seeing the same confusion. Someone pulls up a DDL file, a folder of dbt or SQL, or an ERD reverse-engineered from a Postgres instance and says: “Here’s our data model.”<br>Not to be pedantic, but that’s a schema. Schemas are great. But data modeling is more than just schema design. Let’s dive into the difference.<br>How We Lost the Plot, and How Everything Became a Model

One of the most persistent misconceptions in our industry is that data modeling and schema design are the same thing. While deeply related, they solve fundamentally different problems. Schema design is the act of implementation, while data modeling is the act of representation. This confusion isn’t accidental but rather a product of our historical reliance on relational databases, in which the physical structure became so dominant that it eventually consumed the meaning it was meant to hold.<br>The conflation of model and schema has deep roots. The irony is thick, because the relational model was a model. Codd’s 1970 paper argued for data independence, the idea that people using the data shouldn’t have to care how it’s physically stored. Logical up here, physical down there, a clean wall between them. Then we spent the next fifty years welding the two back together.<br>Chen gave us entity-relationship (ER) modeling in 1976 as a way to argue about reality before anyone wrote code. Draw the entities. Fight about what they mean. Then build.<br>Those things didn’t remain in the mainstream. But physical schema design did. Write the DDL, commit it to Git, and go home. The DDL was visible, durable, and executable, whereas the conceptual model was none of those things and was perceived as busywork. Look at the top skills promoted for data professionals. Usually, SQL is at the top of the list. Data modeling is often nowhere to be found.<br>Then ORMs finished the job. Open a Django project. The file is called models.py. Rails puts it in app/models. An entire generation of engineers learned that a “model” is a class with columns hanging off it, and that class maps one-to-one to a table.<br>And then the modern data stack came along, and dbt started calling a SELECT statement a model (mad love to dbt btw). But add up how “model” is used nowadays. “Model” now means an ERD, a table definition, a SQL transform, a Python class, an regression model, and a several-hundred-billion-parameter transformer.<br>This is why I have “model blindness.” When a word like “model” means everything, it means nothing.<br>What Data Modeling Actually Does

As I write in my upcoming book, Mixed Model Arts, data modeling can apply to all forms of data. Here we’re going to focus on structured data, which is most commonly found in databases. Data modeling happens before you touch a database. It’s a linguistic exercise wearing a technical costume. You’re arguing with other humans (and now AI) about what’s true.<br>What things exist?

What are they, exactly?

How do they relate?

What rules govern them?

How do they change over time?

Who gets to interpret them, and how?

Take the world’s most boring example: an active customer.<br>Marketing says it’s anyone who logged in during the last 30 days. Finance says it’s anyone currently paying. Support says it’s anyone with an open account, paid or not. Product says it’s anyone who’s completed the onboarding flow, because that’s the number in their OKR.<br>All four are right inside their own world. All four will build a query that returns a defensible number. And none of that has anything to do with a database.<br>Modeling means dragging that fight into the open, settling it, and writing down the answer. It’s slow. It’s political. It’s the actual work that data practitioners should do, but often ignore. But ignoring the work doesn’t make it go away. As we all know, the work we ignore will pop up in very painful ways if it’s not addressed up front.<br>What Schema Design Does

Schema design takes that answer and deals in the mechanics:<br>Tables or documents?

How normalized?

Keys?

Indexes?

Partitions?

Constraints?

Physical layout?

Which engine? What is it great at and what does that engine punish you for?

Every one of those is a real question, and getting them wrong will hurt you. They’re also all downstream questions. You can’t answer any of them well until you know what you’re representing.<br>One Model, Many Schemas

The flow runs one direction:<br>Reality → shared understanding → data model → schema design → database.<br>Or shorter: meaning → representation → implementation.<br>Think about sheet music. A score can be played on a piano, a guitar, or by a marching band in a rainstorm. The song is instrument agnostic. Nobody confuses the piano or the guitar with the composition.<br>Same with a customer. That entity can live as a normalized set of...