Data Modelling in 2026

I keep walking into teams having the wrong argument.

They're deep in it. Kimball or Data Vault. Star schema or one big table. Whether the medallion architecture is real engineering or a Databricks slide. Meanwhile the company can't agree on what an active user is, half the dbt project is models nobody queries, and the CEO still re-checks the revenue number by hand before the board call. The modelling method is rarely the real problem. Teams wear themselves out on the religion that grows up around it.

After about fifteen years building data at fintechs, most of it spent cleaning up stacks other people left behind, the take I'll defend is this: the technique wars are over, and the answer is boring. You layer. The questions actually worth arguing about in 2026 are how much to model, how well, and whether a machine can use what you built without lying about it.

The methodology wars ended in layering

Run the "is X dead" question fast and it mostly dissolves.

Kimball is alive, just adapted. Facts, dimensions, grain, conformed dimensions, a Type 2 slowly-changing dimension: that vocabulary is the water every BI tool swims in. What's faded is building strict multi-table star schemas all the way to the dashboard. More often the star is the foundation and you serve a wide table on top. The cargo-cult version is reflexively adding surrogate keys and snowflaked dimensions because "that's Kimball," on a warehouse where none of it earns its keep.

Inmon is a zombie, in the nicest sense. Almost nobody greenfields a normalized enterprise warehouse before building a single mart anymore. But the idea he was right about, an integrated layer that reconciles your sources into one version of the truth, is everywhere, just wearing new names: medallion's "silver," the lakehouse integration tier, Data Vault's raw layer. Inmon himself now writes that the two camps converge on the same hub-and-spoke shape.

Data Vault is alive in a cage. For a bank with forty source systems and auditors who want to know what every number looked like on a Tuesday in 2021, hubs and links and satellites are exactly right. For a startup with five stable sources, it's a way to turn one question into a ten-table join. The rule that saves you: Data Vault is an integration layer that sits underneath. You still put a star or a wide table in front of it for anyone to actually query.

The one debate that's still live is normalization itself, and it's live because its premises moved. Kimball denormalized in the nineties because storage was expensive and row-store databases choked on joins. Both of those stopped being true. Cheap object storage made redundancy nearly free, so denormalizing (star, then wider, then one big table) became the analytical default. Then the newest columnar engines got so good at joins that ClickHouse now says the quiet part out loud: "joins are no longer a constraint that automatically forces your modeling decisions," and "normalization is now a genuinely viable option." The old rule flipped, and now it's being re-examined all over again.

You can see the settlement in how the good teams actually build. Monzo published their setup in 2026: a governed mesh of more than twelve thousand dbt models across a hundred-plus teams, where cross-team "interfaces" are declared contracts, each model built around a single entity with its history. That is hand-modelling scaling up in the age of AI. Airbnb's Minerva defines every metric once and denormalizes facts and dimensions into analysis-ready tables downstream, which is a star schema feeding a semantic layer. GitLab does the whole thing in the open: sources, then staging, then Kimball-named fct_ and dim_ marts, and marts only ever built from facts and dimensions. Different companies, same shape: a layer chosen for each job, one at a time.

So that's the first thing to let go of. The methodology isn't your identity. The move is to choose per layer and per constraint: how much audit do you need, how volatile are the sources, how big is the team, how expensive is the join. A star here, a wide table there, an integration layer underneath if the sources justify it.

Now: keep a dimensional core, materialize wide tables for the dashboards that hate joins, and hold the line on layer discipline. Next: the modelling starts to write itself. Tools already draft models and their metric definitions from a prompt; the human moves from typing SQL to owning what the definitions mean.

The real skill is how much, and how well

Once you stop arguing about method, the actual craft shows up, and it has two halves.

The first is restraint: how much to model. The instinct of a good data team is to model everything into a tidy warehouse. Resist it. A persisted model is an interface, and an interface is only worth building when it's stable and shared. Build one when there's real repetition, when a definition is contested and several teams depend on it, or when a transform is expensive enough to precompute. Otherwise, let the question live in the BI tool and move on. dbt's own guidance says it plainly: "start simple and only add complexity as necessary." The deliberate act is often the decision not to persist yet.

Most over-engineering is a failure of this nerve: a fifteen-tool stack for an eighteen-person company, a medallion architecture where staging and marts would do, a data mesh with one data hire. Benn Stancil has the sharpest read on why it happens: the tooling debate is "a fun distraction from what we actually need to do: fix people and process problems." And the scale that supposedly justifies the machinery usually isn't there. Jordan Tigani's line has aged into consensus: big data is dead, "data size wasn't really the problem at all," and most companies' working set fits comfortably on one machine.

The second half is the part people are quietly nervous about. Knowing how to model well is more valuable now than it has ever been. The fear is that AI makes modelling obsolete, that you can point a model at raw tables and skip the boring part. It's backwards. Chad Sanderson put the pre-AI version of this well: without modelling, "a data warehouse quickly becomes a data swamp." AI raises the stakes on that, because now a machine is reading your swamp and reporting numbers from it with total confidence. The dbt community's own survey lands in the same honest place: teams are using AI everywhere, they're investing to accelerate their data people, and the single most common problem they report is still poor data quality. The craft got more load-bearing.

Who does it? For most companies the answer is a small central team of analytics engineers, the people who sit between the engineers moving data and the analysts using it. Data mesh, pushing modelling out to every domain team, is a real answer at true enterprise scale and an expensive costume below it. If you have one data hire, a mesh is just that person with a grander title.

Now: right-size everything, start simple, and treat modelling as a craft you staff for, not a chore you automate away. Next: models get drafted by agents and reviewed by humans, but someone still has to own what "revenue" means, and that someone is you.

"AI-ready" is a battle, not a checkbox

Half the internet sells "AI-ready data" as a state you reach: clean your models, buy a semantic layer, and the agents just work. That's not what happens.

Start with the good news, because it's real. On clean, well-named data, modern models are strong at simple questions. Point a good model at a tidy schema and ask "how many orders shipped last week by country" and it will nail it, over and over. Well-modelled data does eliminate a whole class of hallucination: the failures that came from cryptic column names and dirty values. That's not nothing. That's most of your everyday BI.

Then the question gets one notch harder, and the floor drops out. This is the part the demos never show you. There's a benchmark, Spider 2.0, that tests models on real enterprise databases, the kind with a thousand columns and business logic nobody wrote down. The same models that clear ninety percent on tidy textbook databases solve about a fifth of the tasks on real enterprise ones, and the weaker ones far less. One frontier model went from 87% on the easy benchmark to 10% on the hard one, which tells you the hard version is a different task entirely.

And the reasons are painfully familiar to anyone who's actually built analytics, because they're the same things that trip up a new analyst:

• Grain. The model joins two tables on the wrong key, silently doubles the rows, and hands you revenue that's twice what it should be. It looks fine. It's wrong.
• Definitions. "Active user" excludes internal employees, at your company. The model has no way to know that. It picks a plausible column and answers with confidence.
• The rules that live in Slack. The real business logic, the fiscal calendar, the exclusions, the "we don't count that region," lives in old threads and PRDs, not in the schema. The model can't read what you never wrote down.

A clean schema doesn't fix any of these, because none of them are in the schema. That's the whole point. Good modelling is necessary and nowhere near sufficient.

The practical response is not a magic box. You wrap the model in the same boring rigor you'd give a junior analyst you don't fully trust yet. In practical terms, for analytics people rather than AI researchers:

1. Put governed metrics in front of it for the numbers that matter. A semantic layer means the model asks for "revenue" and gets your revenue, computed your way, instead of writing its own SQL and guessing. dbt's own test found this took a well-modelled project from about 90% to near-perfect. The failures turn into "I can't answer that" instead of a wrong number, which is exactly the trade you want.
2. Keep the questions inside what you've modelled. The model is reliable on the paths you've paved and dangerous off them. Scope it to what's governed, and let it fail loudly when someone asks something you haven't modelled, rather than inventing an answer under the radar.
3. Make it check its own work. Run the query, then reconcile the total against a number you already trust. The good AI analytics systems all do a version of this, run-and-verify. You should too.
4. Let it say "I don't know." This is the one most teams skip, and it's the most important. A model that abstains on the questions it can't answer is worth far more than one that answers everything and is wrong a third of the time. Reward the shrug.
5. Keep a human on the hard ones. The grain traps, the as-of joins, the definitions that live in someone's head: those still need a person who knows the model. That person is the analytics engineer you were told AI would replace.

None of this is exotic. It's the semantic layer you were half-building anyway, plus the discipline of not trusting a confident machine any more than you'd trust a confident stranger. A shipped system at LinkedIn, with a knowledge graph doing the grounding, runs at about half its answers correct-or-close in production. Half. That's the honest state of the art on hard enterprise questions, and it's why "AI-ready" is a direction of travel with a real ceiling, not a finish line.

Now: put a semantic layer in front of the numbers that matter, scope the agent to what's modelled, make it self-check, and let it abstain. Next: the model queries your governed layer instead of writing raw SQL at all, and modelling becomes the interface between the business and the machine, which is to say more central than ever.

A note on tools, kept short

The tool churn is real and mostly a sideshow. dbt is still the center of gravity, now faster and merged into Fivetran; SQLMesh is the sharper challenger that pushed the whole field forward; Iceberg won the table-format argument, so the warehouse is becoming a swappable engine over shared files; and DuckDB is the reminder that a lot of you could run your whole analytics stack on a laptop. Pick the smallest set that covers your actual problem, and remember the modelling is doing the real work either way.

The point was never the model

A data model earns its keep from one thing: the decisions it holds up, and now, the machines it lets act without lying. Being modern or clever has nothing to do with it.

So model deliberately, and layer honestly, one choice per constraint. Build for how much and how well. When the next AI demo dazzles the room, remember that a confident answer and a correct one come apart on exactly the questions that matter, and closing that gap is the whole job of a data model. That's the spine. Everything else is fashion.