The Database Is Not the Data Model

Representation vs Implementation

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.”

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.

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.

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.

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.

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.

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.

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.

This is why I have “model blindness.” When a word like “model” means everything, it means nothing.

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.

• 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.

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.

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.

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.

What Schema Design Does

Schema design takes that answer and deals in the mechanics:

• 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.

One Model, Many Schemas

The flow runs one direction:

Reality → shared understanding → data model → schema design → database.

Or shorter: meaning → representation → implementation.

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.

Same with a customer. That entity can live as a normalized set of relational tables, a wide denormalized table in Iceberg, a JSON document, a Parquet file in S3, an Excel file, or a node in a graph. Same meaning, different physics. That’s a feature. It means you can change the instrument without rewriting the song. I could even play Aha’s “Take on Me” on a shitty flute if I want (definitely worth a listen).

The reverse direction is the dangerous one. A single schema can quietly support several models at once, which is the magic moment when three teams query customers, each gets a technically correct answer, and the three answers can’t be reconciled. Nobody wrote a bug. Everybody wrote a different song off the same page. This is where ignoring the hard work of representation comes back to haunt you, often taking the form of infighting about definitions and a lack of trust. Perhaps you’ve been there.

Machines Don’t Have Tribal Knowledge

Here’s where this stops being an academic distinction.

An agent pointed at your warehouse sees tables, columns, keys, and (hopefully) comments. It does not see the Slack thread from 2023 where you all decided a canceled subscriber still counts as active for 90 days. It doesn’t see the face your senior analyst makes when someone asks about orders_v2.

Humans constantly compensate for broken models, and we do it without noticing. You know fct_orders double-counts refunds, so you filter them out. Every time. Forever. And you never write it down, because you’re busy and everyone who matters already knows. That unwritten knowledge is the real model. The schema is the artifact.

An LLM or agent has no background knowledge. It reads exactly what’s there and confidently joins tables that were never meant to meet. Then it hands you a number, formatted nicely, with a friendly explanation of its reasoning. Might be wrong, but it’s presentable.

This is precisely when teams nowadays reach for a semantic layer. And look, semantic layers are useful. But most of the ones I see are compensating for modeling decisions that never got made. You end up paying rent forever on a translation dictionary between your schema and your meaning, because nobody wrote down the meaning back when it was cheap. Or more to the point, the meaning wasn’t agreed upon in the first place.

The Bill Always Comes Due

There’s no free lunch with data modeling. Focusing only on schema design at the expense of data modeling means the bill always comes due. Here are some ways you get to pay.

• Migrations get brutal. Meaning is welded to physical structure, so moving off Postgres means re-deriving what your business means, under deadline, at the worst possible time.

• Integrations become archaeology. Merging two companies’ data isn’t a transfer job. It’s a translation project where both dictionaries are missing, and nobody can translate between the two data systems.

• Governance drifts into theater. You catalog PII, retention, ownership, lineage. All useful. None of it tells a single human being what a customer is.

• AI underperforms, and the AI takes the blame. The model isn’t confused. Your data is. But your company just fired the data team because AI’s awesome, so whatever.

• Teams argue over names rather than concepts. Weeks of bikeshedding over cust_id versus customer_id, while nobody has established whether the two tables mean the same damn thing.

The Two Questions

Data modeling asks: what does this represent?

Schema design asks: how should we implement it?

Models preserve meaning. Schemas preserve structure. And meaning has to outlive structure, because structure churns. Your understanding of a customer should survive four database migrations, two acquisitions, a re-platform, and whatever we’re all running in 2032.

Treat the schema as the final mile of the model. It’s the last step, not the whole trip.