Data Vault vs Kimball in Azure: What Dutch Teams Actually Build

Scenario: A Dutch Retailer Moving to Azure

Imagine a mid-sized Dutch retailer with:

• Sales data from POS systems
• E‑commerce events
• Product and inventory from ERP
• Customer data from CRM and marketing tools

They’re moving from an on‑prem SQL Server warehouse to:

• Azure Data Lake Storage Gen2 as the raw landing zone
• Azure Synapse Analytics (dedicated SQL pool) or Fabric Warehouse for the core warehouse
• Power BI for reporting

The legacy warehouse is classic Kimball:

• Star schemas for Sales, Inventory, Customer
• Slowly Changing Dimensions (mostly Type 2)
• ETL in SSIS and SQL stored procedures

New hires and consultants keep pushing “Data Vault 2.0 on Azure”. Job ads mention:

• Hubs, links, satellites
• Raw vault and business vault
• Automation tools generating metadata‑driven ELT

The architecture team now has to decide:

• Do we rebuild the core model in Data Vault?
• Do we keep Kimball and just modernise the platform?
• How do we avoid two competing models that nobody fully owns?

We’ll walk through how this retailer can combine both approaches in Azure without creating a mess.

Quick Refresher: What Data Vault 2.0 Actually Brings

Data Vault 2.0 is not just “more tables” or “yet another modelling fad”. It’s a specific way to structure the enterprise data warehouse layer:

• Hubs: business keys (Customer, Product, Store, Order) with surrogate keys
• Links: relationships between hubs (Customer–Order, Order–Product)
• Satellites: descriptive attributes and history tied to hubs or links

Core properties that matter in Azure:

1. Insert‑only pattern

   • Satellites typically store full history; you insert new records rather than updating existing ones.
   • Works well with append‑optimised storage and batch ELT patterns.

2. Separation of concerns

   • Business keys and relationships are separated from descriptive attributes.
   • Makes it easier to add new source systems and new attributes without re‑working the core structure.

3. Auditability and lineage

   • Load dates, record sources, and hash keys (where used) make data provenance explicit.
   • Helps with regulatory and cross‑system reconciliation scenarios.

On Azure, Dutch teams often implement Data Vault 2.0 as the enterprise warehouse layer in:

• Synapse dedicated SQL pools, SQL Database, or Fabric Warehouse
• With ELT pipelines in Synapse Pipelines, Azure Data Factory, or Fabric Data Factory

Quick Refresher: Kimball in an Azure Context

Kimball dimensional modelling is what most BI developers in the Netherlands already know:

• Fact tables: transactions, balances, events
• Dimension tables: customers, products, stores, dates
• Star schemas: facts surrounded by conformed dimensions

Core properties that matter in Azure:

1. Reporting‑friendly

   • Power BI, Excel, and other tools work naturally with star schemas.
   • Measures and relationships are straightforward for analysts.

2. Business‑oriented

   • Dimensions are shaped to match business language.
   • Facts are aligned with business processes (Sales, Inventory, Orders).

3. Performance‑optimised for analytics

   • Fact tables can be partitioned and indexed (in Synapse/Fabric warehouses).
   • Columnstore indexes in Synapse/Fabric are well suited to large facts.

Most existing Dutch warehouses are Kimball‑centric. Even when Data Vault is introduced, reporting layers often remain dimensional.

Where Dutch Companies Actually Use Data Vault vs Kimball

Patterns you’ll see in practice in Dutch Azure environments:

1. Data Vault for the core, Kimball for the marts

   • Raw data lands in ADLS.
   • Data Vault 2.0 implemented in Synapse/Fabric as the integration layer.
   • Kimball star schemas built on top as presentation marts for Power BI.

2. Kimball‑only in smaller teams

   • When sources are limited and governance needs are modest, teams often keep a simpler dimensional warehouse.
   • Azure SQL Database or Synapse used like a modern SQL Server warehouse with star schemas only.

3. Hybrid with partial Data Vault

   • Some domains (e.g. Customer, Product) are modelled in Data Vault.
   • Others remain in legacy Kimball due to time constraints.

Job ads mentioning “Data Vault 2.0” usually indicate:

• A central data platform team building an enterprise warehouse layer.
• A desire to standardise ingestion and history across many domains.
• Power BI still sitting on dimensional models or semantic models.

Mapping Data Vault to Azure Components

Using our retailer scenario, a common Azure implementation looks like this:

1. Landing and Staging in ADLS / Lakehouse

• Raw zone: source‑aligned files in ADLS Gen2 or Fabric Lakehouse.
• Staging zone: lightly cleaned and typed tables, often in Lakehouse or Synapse.

This layer is usually not Data Vault or Kimball. It’s technical staging.

2. Data Vault in Synapse or Fabric Warehouse

Core Data Vault structures:

• HubCustomer, HubProduct, HubStore, HubOrder
• LinkCustomerOrder, LinkOrderProduct, etc.
• Satellites like SatCustomerCRM, SatCustomerMarketing, SatProductERP

A simple example of a hub table in Synapse/Fabric Warehouse:

CREATE TABLE dbo.HubCustomer
(
    HubCustomerKey      BIGINT IDENTITY(1,1) NOT NULL,
    BusinessCustomerKey NVARCHAR(50)        NOT NULL,
    LoadDateTime        DATETIME2(3)        NOT NULL,
    RecordSource        NVARCHAR(100)       NOT NULL,
    CONSTRAINT PK_HubCustomer PRIMARY KEY CLUSTERED (HubCustomerKey)
);

And a satellite table capturing CRM attributes:

CREATE TABLE dbo.SatCustomerCRM
(
    HubCustomerKey BIGINT         NOT NULL,
    LoadDateTime   DATETIME2(3)   NOT NULL,
    RecordSource   NVARCHAR(100)  NOT NULL,
    CustomerName   NVARCHAR(200)  NULL,
    EmailAddress   NVARCHAR(200)  NULL,
    Status         NVARCHAR(50)   NULL,
    ValidFrom      DATETIME2(3)   NOT NULL,
    ValidTo        DATETIME2(3)   NULL,
    CONSTRAINT PK_SatCustomerCRM PRIMARY KEY CLUSTERED (HubCustomerKey, LoadDateTime),
    CONSTRAINT FK_SatCustomerCRM_HubCustomer FOREIGN KEY (HubCustomerKey)
        REFERENCES dbo.HubCustomer (HubCustomerKey)
);

This structure works reliably in:

• Synapse dedicated SQL pools (with appropriate distributions and indexes)
• Fabric Warehouse (with clustered columnstore or rowstore as needed)

3. Kimball Marts for Power BI

From the Data Vault layer, the team builds dimensional models:

• DimCustomer, DimProduct, DimStore, DimDate
• FactSales, FactOrder, FactInventory

Example: creating a DimCustomer view from HubCustomer + satellites:

CREATE VIEW dbo.DimCustomer AS
SELECT
    hc.HubCustomerKey          AS CustomerKey,
    hc.BusinessCustomerKey     AS CustomerBusinessKey,
    sc.CustomerName,
    sc.EmailAddress,
    sc.Status,
    sc.ValidFrom,
    sc.ValidTo,
    sc.RecordSource,
    hc.LoadDateTime            AS FirstSeenDateTime
FROM dbo.HubCustomer hc
CROSS APPLY
(
    SELECT TOP (1)
        s.CustomerName,
        s.EmailAddress,
        s.Status,
        s.ValidFrom,
        s.ValidTo,
        s.RecordSource
    FROM dbo.SatCustomerCRM s
    WHERE s.HubCustomerKey = hc.HubCustomerKey
      AND s.ValidTo IS NULL
    ORDER BY s.ValidFrom DESC
) sc;

Power BI then connects to these views (or to a semantic model built on top) and uses standard dimensional modelling patterns.

Why Data Vault Shows Up in Dutch Job Ads

From what practitioners see locally, Data Vault appears in Dutch job ads for a few practical reasons:

1. Multi‑source integration is the norm

   • Retail, finance, logistics, and public sector teams integrate numerous SaaS and on‑prem systems.
   • Data Vault’s hub/link/satellite pattern helps keep that complexity manageable.

2. Regulatory and audit requirements

   • Many organisations need to explain data lineage and historical changes.
   • Data Vault’s explicit load dates and record sources align well with those needs.

3. Platform teams want repeatable patterns

   • A central Azure data platform team can standardise ingestion and modelling across domains.
   • Data Vault lends itself to metadata‑driven ELT and automation.

4. Consultancies and vendors promote Data Vault 2.0

   • Implementation partners often bring Data Vault templates and frameworks.
   • Job ads reflect the patterns those partners help establish.

However, the reporting layer in these organisations is still mostly Kimball or semantic‑model‑centric. Analysts and BI developers rarely work directly with hubs and satellites.

Choosing Between Data Vault and Kimball for Your Azure Platform

Back to our retailer: they need a practical decision, not a theoretical debate.

When a Data Vault Core Makes Sense

Consider a Data Vault 2.0 core if:

• You have many source systems with overlapping domains.
• You need full history and auditability across those sources.
• You’re building a central platform serving multiple teams and products.
• You plan to invest in automation (template‑driven pipelines, code generation).

In Azure terms:

• Use Data Vault in Synapse dedicated SQL pool or Fabric Warehouse as the integration layer.
• Land raw data in ADLS/Lakehouse, then standardise ingestion into hubs/links/satellites.

When Staying Kimball‑First Is Fine

A Kimball‑only approach can be perfectly valid if:

• You have limited sources and relatively stable schemas.
• Your main goal is fast delivery of Power BI reports.
• Your team is small and primarily BI‑focused.

In Azure terms:

• Use Azure SQL Database, Synapse, or Fabric Warehouse with star schemas.
• Keep staging simple and focus on dimensional models.

Hybrid: The Common Dutch Compromise

Most mature Dutch Azure platforms end up with:

1. Raw lake in ADLS/Lakehouse
2. Data Vault integration layer in Synapse/Fabric Warehouse
3. Kimball marts or Power BI semantic models on top

This gives:

• A stable, auditable backbone for ingestion and history
• Familiar dimensional structures for reporting
• A clear separation between platform concerns and BI concerns

Practical Tips for Implementing Data Vault 2.0 on Azure

For teams that decide to go Data Vault‑centric on Azure, a few practical points matter more than methodology debates.

1. Be Explicit About the Layer Boundaries

Define three layers clearly:

• Staging: source‑aligned, minimal transformation.
• Raw/Business Vault: Data Vault structures, insert‑only history.
• Marts/Semantic: Kimball or business‑friendly views for Power BI.

Document:

• Which layer is the truth for history and lineage (usually the vault).
• Which layer is the truth for metrics and KPIs (usually marts/semantic models).

2. Align Distribution and Indexing with Workloads (Synapse)

If you’re using Synapse dedicated SQL pools:

• Choose distribution strategies appropriate for hubs/links/facts.
  • Hubs often work with hash distribution on the surrogate key or business key when joins are frequent.
  • Reference data can use replicated distribution for small dimensions.
• Use clustered columnstore indexes for large tables where analytical queries dominate.
• Use rowstore indexes where selective lookups or small tables are common.

Check current Synapse documentation for distribution and index recommendations; they may evolve with engine improvements.

3. Keep Satellites Targeted

Avoid satellites that mix:

• Attributes from many different source systems
• Attributes with very different change frequencies

Instead:

• Create satellites per source and subject area (e.g. CRM vs ERP attributes).
• This reduces unnecessary churn and makes history easier to interpret.

4. Automate What’s Repetitive, Not What’s Complex

Data Vault invites automation, but:

• Automate patterns (hubs, links, satellites, load frameworks).
• Keep business rules explicit and reviewable.

On Azure, this typically means:

• Metadata‑driven pipelines in Synapse Pipelines/Data Factory/Fabric Data Factory.
• Code generation for table DDL and basic ELT.

5. Expose Dimensional Views Early

Don’t force report developers to work directly on hubs and satellites.

• Provide dimensional views or semantic models as soon as a domain stabilises.
• Use Power BI relationships and measures on top of those views.

This keeps the Data Vault complexity within the platform team and gives analysts a familiar surface.

One Concrete Takeaway

If you’re designing an Azure data platform in the Netherlands and keep seeing “Data Vault vs Kimball” discussions, start by deciding layers, not winners: use Data Vault 2.0 for the integration and history layer where governance and multi‑source complexity matter, and keep Kimball (or dimensional semantic models) for the reporting layer where Power BI users live.