Change shared models without breaking everyone
When a shared model changes, it can silently break every team downstream. Model versions and contracts let a central team ship a new version while consumers migrate on their own schedule.
Central ships @v3 today; @v1 and @v2 keep running, so every team upgrades when its own tests pass.
A shared model is supposed to be the safe, single source everyone builds on. The day it changes is the day that promise can quietly break. A central team renames a column or changes a type in one widely used table, and across the business, dashboards go blank, downstream models fail, and an ML feature starts reading the wrong field. Nobody meant to break anything. The structure simply does not let a shared model change without changing it for everyone, all at once.
The problem
When many teams read directly from the same model, every consumer is coupled to its exact shape. Finance builds margin on it, Marketing builds attribution on it, Product builds activation on it, and none of them knew the others existed. So a change anywhere is a change everywhere, which means the central team cannot safely evolve the model and downstream teams cannot trust it to stay still. People respond the only rational way: they stop changing things. The shared foundation ossifies exactly when the business needs it to move.
What dbt does about it
dbt gives a shared model two guardrails: model versions and contracts. A version lets one model expose several shapes at once. When the central team needs to evolve a definition, they publish v2 and keep v1 running, so the change is additive, not destructive. A contract is a promise about the model’s columns, types and not-null rules, enforced at build time, so a change that would break the agreed shape fails before it ships rather than after a number goes wrong. Together they turn a shared model into a real data product: governed, owned, and safe to depend on as the data mesh intends.
What it looks like
The platform team publishes orders as a versioned, contracted data product. Finance pins orders @v1 for its margin model; Marketing pins it for attribution; Product builds activation on the same base. The team needs to split one column into two, so they ship orders @v2 and leave v1 running. Each downstream team migrates when its own tests pass: Marketing moves this sprint, Finance moves next month, Product later. Three teams move at three speeds on one shared foundation, and not one of them breaks on the morning the change ships.
How we think about it
We help you decide which models deserve to be products, put clear owners on them, and add contracts and versions to the few that everyone depends on. The same discipline starts with change without fear inside a single project, then extends it across teams. A shared change should never be a fire drill. Done well, the central team ships improvements often, and every downstream team upgrades on a schedule it controls.
Change shared models without breaking everyone, in short.
Why does changing one shared model break so many teams?
Because everyone reads from the same model. The moment a central team renames a column, changes a type, or drops a field, every downstream model, dashboard and feature that depended on the old shape can fail or, worse, return a wrong number quietly. With no versioning, a single edit is a change everywhere at once, so the safe option becomes never changing anything.
How do model versions actually prevent breakage?
A shared model can expose more than one version at the same time. When the central team needs to change a column, they publish a new version and keep the old one running. Downstream teams stay pinned to the version they tested against and migrate when their own tests pass. Nothing breaks the morning a central change ships, because each team upgrades when it is ready.
What is a contract and how is it different from a version?
A contract is a promise about a model's shape: the columns it exposes, their types, and which are not null. dbt enforces it at build time, so a change that would break the agreed shape fails before it ships, not after a dashboard goes wrong. Versions let the shape evolve safely over time; contracts guarantee that each version keeps the promise it made while it is live.
Do we need to be a large organisation to use this?
No. The same pattern helps a handful of teams that keep stepping on each other's models. Start with one or two shared models, the ones everyone keeps depending on, and put a contract and a version on those first. The value, safe change on a shared foundation, matters well before you reach enterprise scale.
Keep exploring
Change without fear
Modular, version-controlled models with tests mean a change is reviewed, tested and reversible, not a leap of faith.
One agreed way of working
Bronze, silver, gold layers and reusable models give every team one contract, so questions become queries, not rebuilds.
Faster, cheaper runs
Incremental models process only what changed, so runs are faster, compute costs less, and the warehouse is under less strain.
Want this for your data?
If this is how you want your team to work, we should talk.