Medallion Architecture vs Data Vault: Layers vs a Modeling Method

Medallion architecture and Data Vault are usually compared as rivals, and they are actually answers to different questions. Medallion says how many quality layers your platform has. Data Vault says how to model the tables inside a layer so history survives and sources can change. The real decision is whether your silver layer needs a vault.

The medallion architecture is a layering pattern: bronze lands raw data, silver cleans and conforms it, gold serves it business-ready. Data Vault, created by Dan Linstedt and now in its 2.0 form, is a modeling method: it prescribes the shape of the tables themselves, splitting every entity into hubs (the business keys), links (the relationships between them), and satellites (the descriptive attributes, insert-only, with full history). One tells you the stages data moves through; the other tells you what the tables in a stage look like. They compose rather than compete, and the genuinely contested question, the one this comparison is really about, is what your silver layer should be: plain conformed tables, or a vault.

What does a Data Vault actually look like?

Here is a payments fragment modeled as a vault:

The design has two properties that explain everything else about it. It is insert-only with history: satellites never update, they append, so every version of every attribute is preserved with its load date, and “what did we believe about this account on March 3rd” is a query, not an investigation. And it isolates change: a new source system or a new set of attributes becomes a new satellite hanging off an existing hub, so integration growth does not restructure what is already built. Those are audit and volatility properties, which is why the method’s natural habitat is exactly the regulated, multi-source, prove-your-history environment banks live in.

The same normalization is also why nobody hands a vault to analysts. Answering “settled payments by account type last month” means walking hubs, links, and multiple satellites while picking current rows by load date, so Data Vault methodology itself prescribes a presentation layer on top, typically star schemas, which analysts and BI tools query instead.

Medallion vs Data Vault at a glance

Dimension	Medallion architecture	Data Vault
Category	Layering pattern (quality stages)	Modeling method (table design)
Prescribes	Bronze, silver, gold stages	Hubs, links, satellites
History handling	Not prescribed; bronze keeps raw	Built in: insert-only satellites with load dates
Source volatility	Not prescribed	Isolated: new sources become new satellites
Analyst-facing?	Gold layer is	No; requires a presentation layer on top
Complexity	Low concept count	High table count and discipline
Natural habitat	Any lakehouse or warehouse	Regulated, multi-source, audit-heavy estates
Relationship	Can host a vault as its silver layer	Slots into medallion’s silver

So what is the actual decision?

Not medallion or vault; the decision is what silver is made of. Every platform ends up with something medallion-shaped, raw in, business-ready out, whatever names it uses. The contested middle has two honest options. Conformed plain tables: cleaned, deduplicated, entity-shaped models, the dbt staging-and-intermediate convention, cheap to build, easy to read, history handled selectively where it matters. A Data Vault: the full hub-link-satellite discipline, expensive in table count and skills, buying complete attribute history, source-change isolation, and an audit posture regulators recognize.

The selection criteria are the vault’s two properties, applied as a fit-gap against your reality. Many volatile sources that must integrate on shared business keys? The change isolation earns its cost. A regulatory obligation to reconstruct any past state of the data? The insert-only history earns it, and hand-rolling the same guarantees onto plain tables ends up rebuilding a worse vault. Neither condition true? The vault is machinery without a mission, and its complexity becomes pure overhead between your sources and your gold-layer marts. Be honest about the skills question too: a vault built without vault discipline, the naming, the loading patterns, the key handling, delivers the table count without the guarantees.

The takeaway

Medallion is a layering pattern; Data Vault is a modeling method; the real question is whether your silver layer should be a vault. Choose the vault when multi-source volatility and audit-grade history are genuine requirements, and serve analysts through star schemas on top either way. Choose plain conformed tables when they are not, and spend the saved complexity on tests and definitions instead.