Can I combine two data warehouse methodologies?

Yes, and most real warehouses do. Data Vault with dimensional marts on top is the common pairing, and Medallion with a star schema in gold is almost the default. What does not work is two models competing at the same layer, where the same question can be answered two ways and the answers differ.

Eight ways to model a data warehouse, and how to choose between them

Q: Which data warehouse methodology is best?

None of them in general - each makes something easy and something else expensive. The useful question is which one fits the data you have: how many systems feed it, whether history matters, and who writes the queries at the end.

Q: Do I need a staging layer in a data warehouse?

In practice yes, whichever methodology you choose. It keeps the transformation off the production system, gives a failed load somewhere to restart from, and is the one place the data still looks like the source when a number needs checking.

Kimball, Inmon, Data Vault 2.0, Medallion, Galaxy, One Big Table, Anchor Modeling and Activity Schema. Most writing on these explains what each one is. This is about which one your data is asking for — including what each costs and where each one hurts.

On this page

The short answer
Kimball — dimensional modelling
Inmon — the Corporate Information Factory
Data Vault 2.0
Medallion — bronze, silver, gold
Galaxy — the fact constellation
One Big Table
Anchor Modeling
Activity Schema
The six questions that actually decide it
Where staging fits, whichever you pick
Questions people ask

The short answer

There is no best one, and anybody who tells you otherwise is telling you about their last project rather than about your data. Each of the eight is a trade: something is made easy and something else is made expensive. What decides it is the shape of what you have — how many systems feed you, how much history matters, and who writes the queries at the end.

If this is your situation	Start here
One source system, and people want to report on it	Kimball
Several processes sharing the same customers and products	Galaxy
Several source systems that disagree about the same customer	Inmon or Data Vault
You must be able to prove what you received and when	Data Vault 2.0
The source schema changes constantly	Data Vault or Anchor
You are on a lakehouse and want the pipeline organised	Medallion
One process, few joins, analysts who dislike SQL	One Big Table
The questions are about what happened, and when, and in what order	Activity Schema

Read that as a starting point rather than a verdict. The eight sections below say what each one costs, which is the part that decides whether you can live with it.

Kimball — dimensional modelling

Also called: star schema, dimensional model, fact and dimension tables

Facts surrounded by dimensions. A fact table holds the things you measure — an order line, a payment, a reading — and the dimensions hold the things you slice by: customer, product, date, store. Built for people asking business questions in a reporting tool.

When it fits: Reporting and BI, where the questions are "how much, by whom, when". It is the model every BI tool expects, so the tooling is on your side.
When it does not: When nothing in your data classifies as a fact or a dimension — a schema of reference lists has no star in it. And when several source systems describe the same customer differently, the disagreement has to be resolved before the dimension can exist, which is a job Kimball does not do for you.
What it costs: Two decisions you cannot avoid and cannot cheaply undo: the grain of each fact — exactly what one row means — and how much history each dimension keeps, the slowly changing dimension question. Getting the grain wrong is the expensive mistake in this methodology, because everything downstream assumes it.

Kimball in full: the grain, the star, and the SCD decision →

Inmon — the Corporate Information Factory

Also called: CIF, the enterprise data warehouse, 3NF core

A normalised, integrated core modelled on the business rather than on any one system, with dimensional marts built on top of it. The core is the single version of the truth; nobody queries it directly, and the marts are disposable views of it.

When it fits: Several source systems that each hold part of the same customer, and an organisation that will still be here in ten years. The integration is the point: one customer, one definition, whatever the source called them.
When it does not: With a single source system the integration layer is doing very little, and Kimball reaches the same reports with half the work. It is also poorly suited to a team that needs something useful this quarter.
What it costs: Two layers to build, load and maintain, and the marts are not optional — nothing reports off the core directly. Budget for both or the warehouse is finished and unusable at the same time.

Inmon in full: the 3NF core and the marts on top →

Data Vault 2.0

Also called: hubs, links and satellites; DV2.0; the raw vault

Business keys go in hubs, relationships between them in links, and everything else in satellites that are only ever inserted into, never updated. Nothing is thrown away, so the warehouse can always say what it was told and when.

When it fits: Many sources, schemas that change often, and anywhere auditability is a requirement rather than a nice-to-have — regulated industries especially. Adding a source adds tables rather than rewriting existing ones, which is the property people buy it for.
When it does not: When there are no relationships in your data there is nothing for links to hold, and what is left is an elaborate copy. It is also the wrong answer for a small warehouse that one person reports off.
What it costs: Table count, and a second layer. Analysts must never query the raw vault directly — it is not built for reading — so the marts on top are part of the project, not a later phase. There is no slowly-changing- dimension question here, because keeping history is the mechanism rather than an option.

Data Vault 2.0 in full: hubs, links, satellites and hash keys →

Medallion — bronze, silver, gold

Also called: the multi-hop architecture, bronze/silver/gold layers

Land everything raw in bronze exactly as it arrived, clean and deduplicate it into silver, and publish business-ready tables in gold. Popularised by the lakehouse world and now the default shape of a great many pipelines.

When it fits: Ingest-first work where you want to keep the original bytes, and teams who need the pipeline's stages to be obvious. Bronze is genuinely valuable: it can prove what was received.
When it does not: Here is the honest part: Medallion organises the work, it does not model the business. It tells you where a table sits in the pipeline, not what a row means. Most teams end up putting a star schema in gold anyway — which is to say they end up doing Kimball as well, not instead.
What it costs: The same data stored three times. On a lakehouse that is cheap; on a traditional database it is a real bill.

Medallion in full: what belongs in bronze, silver and gold →

Galaxy — the fact constellation

Also called: fact constellation, conformed dimensions, the bus matrix

Several fact tables sharing the same dimensions. One customer table serving sales, support and returns, so that a question can cross between processes and still mean something.

When it fits: More than one business process, with genuinely shared master data. It is Kimball grown up, and the natural destination of a warehouse that started with one star.
When it does not: With one fact table there is no constellation, only a star. And a dimension is only conformed if every process agrees on what it means — which is an organisational agreement, not a technical one. Where that agreement does not exist, a shared dimension quietly becomes a source of wrong answers.
What it costs: The conversations. The modelling is straightforward; getting two departments to agree what "active customer" means is not.

Galaxy in full: conformed dimensions and the bus matrix →

One Big Table

Also called: OBT, the wide table, denormalised table

One wide table per subject, with everything joined in already, so the person asking the question never writes a join.

When it fits: A single business process, a columnar engine that does not mind wide rows, and analysts who would rather filter columns than reason about keys. It is often the fastest thing to query and the easiest to explain.
When it does not: Every customer detail is repeated on every row, so one correction to a customer's name means rewriting many rows rather than one. There is no history, and the usual way it goes wrong is one table for everything rather than one per process.
What it costs: Storage, and a full rebuild each run — there is no incremental load to speak of. That is the trade the methodology openly makes.

One Big Table in full: when a wide table beats a star →

Anchor Modeling

Also called: 6NF modelling, anchors, attributes, ties and knots

The smallest pieces that can be stored separately. An anchor is an identity and nothing else; every property is its own table; every relationship is its own table. Adding a property never touches an existing table, which is the entire point.

When it fits: Schemas that change constantly and where full temporal history is required — every value, with the moment it became true. Changes are additive by construction, so nothing is ever migrated.
When it does not: Expect roughly one table per column. Nobody queries this by hand, and if you have not planned the reporting views at the same time as the model, you have built something nobody can use.
What it costs: Joins — a great many of them — and a reporting layer that is not optional. Everything the model makes cheap to change, it makes expensive to read.

Anchor Modeling in full: anchors, attributes, ties and knots →

Activity Schema

Also called: the activity stream, event modelling, the customer 360 timeline

One table. Every row is one thing that happened to one entity at one moment — a customer signed up, placed an order, opened a ticket — in a single stream you can read forwards and backwards.

When it fits: Questions about sequence and timing: what happened between signing up and the first order, how long until the second purchase, what preceded a cancellation. Behavioural and customer-journey analysis, where a star schema makes you work hard for answers.
When it does not: It needs an entity and it needs timestamps — an activity with no time cannot be sequenced, so it cannot be in the stream. And the feature columns mean different things for different activities, so the dictionary that says what each one means has to be maintained or the table becomes unreadable.
What it costs: That dictionary, and a rebuild pass after loading to fill the sequence and "when did this next happen" columns that make the model worth having.

Activity Schema in full: the stream, and what it needs →

The six questions that actually decide it

Methodology arguments usually go badly because people compare the models instead of describing the situation. These six answers narrow eight choices to one or two almost every time.

How many source systems feed this? One points at Kimball or One Big Table. Several that disagree about the same entity points at Inmon or Data Vault, because something has to reconcile them.
Does history matter, and whose? If you need to know what a customer's address was last March, that is slowly changing dimensions in Kimball, and it is free in Data Vault and Anchor. If you only ever need "now", say so — it removes half the work.
Who writes the final query? Analysts in a BI tool need a star or a wide table. If only engineers read it, the shape can be anything.
How often does the source schema change? Rarely — any model works. Constantly — Data Vault and Anchor absorb change by adding tables; a star schema absorbs it by being rebuilt.
Do you have to prove what arrived? If audit is a requirement rather than a wish, Data Vault, and bronze in Medallion, both exist precisely for that.
Are the questions about state or about events? "How many customers in Bavaria" is state, and dimensional. "What did they do before they cancelled" is events, and that is Activity Schema.

These answers are in your data already. How many systems feed a table, whether a column changes over time, whether anything looks like a fact, whether the timestamps needed to sequence events even exist — all of it can be measured rather than guessed at. That is what Netune does: it profiles a SQL Server database, scores all eight of these methodologies against what it actually measured, and shows the evidence for each rather than handing down a verdict. You still choose. It just means you choose knowing what is in there.

Where staging fits, whichever you pick

Every one of the eight needs somewhere to put the source data before it is reshaped, and that layer is not a methodology choice — it is plumbing that all eight share. A staging table is a copy of a source table, typed and landed, and nothing else: no keys resolved, no history applied, no business rules.

It earns its place for three reasons. It means the warehouse load reads from your database rather than from the production system, so a slow transformation does not hold a live application hostage. It gives a failed load somewhere to restart from. And it is the only place where the data still looks exactly like the source, which is where you go when a number turns out wrong.

Medallion's bronze is the same idea with a different name and one extra promise: it keeps what arrived, unmodified, so it can prove it later. The longer version, with the four things staging must never do, is what a staging layer is actually for.

Questions people ask

Which data warehouse methodology is best?

None of them, in general — each makes something easy and something else expensive. The useful question is which one fits the data you have, how many systems feed it, whether history matters, and who writes the queries at the end.

Kimball or Data Vault — how do I choose?

Full answer here. In short: Count your source systems and ask whether you must be able to prove what arrived. One system and reporting questions: Kimball, and you will be finished far sooner. Several systems that disagree, schemas that keep changing, or an audit requirement: Data Vault — but budget for the marts on top, because nobody queries a raw vault directly.

Can I combine two methodologies?

Yes, and most real warehouses do. Data Vault with dimensional marts on top is the common pairing, and Medallion with a star schema in gold is so common it is almost the default. What does not work is two models competing at the same layer, where the same question can be answered two ways and the answers differ.

Is Medallion an alternative to Kimball?

Not really — they answer different questions. Medallion says where a table sits in the pipeline; Kimball says what a row means. Most teams who adopt Medallion end up modelling gold dimensionally, which is doing both rather than choosing.

What is a slowly changing dimension, and which type do I need?

Full answer here. In short: It is what happens when an attribute changes — a customer moves. Type 1 overwrites and the old value is gone. Type 2 keeps the old row and adds a new one, so history survives and reports about last year stay correct. Type 2 where the past must stay right; type 1 where only the current value ever matters and the extra rows would be noise.

Do I need a staging layer?

In practice, yes, whichever methodology you choose. It keeps the transformation off the production system, gives a failed load somewhere to restart, and is the one place the data still looks like the source when a number needs checking.

Can any of this be decided automatically?

The evidence can be gathered automatically; the decision should not be. Profiling can tell you how many tables look like facts, which columns change over time, whether relationships exist and whether events carry timestamps. What it cannot tell you is what the business intends to ask in three years — which is why Netune scores the eight and shows its reasoning, rather than picking for you.

See what your own database suggests

Netune reads a SQL Server database, profiles the real data, and scores all eight of these against what it measured — with the reasons shown. Free, runs on your own machine, and nothing it reads leaves it.

Download the free beta