Jaco van der Laan

🧭 Inmon, Data Vault, and Palantir Ontology — Where They Overlap (and Where They Don’t)

25/10/2025  Âˇ  Data Architecture  Âˇ  Data Modeling  Âˇ  Semantic Layer

‹ ›

How historization-first, model-driven data engineering extends classic warehousing and modern semantics.

💡 This article continues from Palantir’s Ontology, Kimball’s Star Schema, and Model-Driven Data Engineering: A Comparative View, responding to reader questions about how these approaches relate to Inmon’s 3NF and Data Vault — and how they look in practice.

The Reader Questions

When I compared Palantir’s Ontology and Kimball’s Star Schema, several readers asked insightful follow-ups:

“An Inmon-style data warehouse is in 3NF, with entities representing business objects and history captured. How is this different from Palantir’s Ontology?” “Sounds like Data Vault.” “Can you show a real-case example?”

These questions reveal something important: all these approaches share the same intent — to model data around business meaning and history — but they differ in how they realize it.

Inmon’s 3NF Warehouse — The Original Business-Entity Approach

Bill Inmon’s Corporate Information Factory organizes data around normalized business entities such as Customer, Account, or Product.
Each entity holds historical records, often using start/end dates or type-2 logic.

✅ Strengths

  • Clear alignment with business objects.
  • Integration across sources at the enterprise level.
  • Support for historization and lineage.

⚠️ Limitations

  • Difficult to evolve; schema changes ripple widely.
  • Heavy ETL dependency and manual transformations.
  • Not easily consumable for analytics or self-service tools.

In essence, Inmon’s 3NF model and Palantir’s Ontology share the same DNA — but Ontology adds semantics and composability, turning relational tables into a graph of business objects enriched with metadata.

Data Vault — Making Historization a First-Class Citizen

✅ What It Adds

  • Built-in historization and audit trail.
  • Structural resilience: new sources and attributes don’t break the model.
  • Separation of concerns between identity, relationships, and context.

⚠️ What It Lacks

  • Complex joins for simple queries.
  • Performance challenges without PIT or bridge tables.
  • Often implemented too literally, leading to unnecessary overhead.

💡 In practice, we borrow the principles of Data Vault — separation of concerns and full historization — but implement them using simpler Dual SCD2 tables instead of literal hubs, links, and satellites.

Palantir’s Ontology — The Semantic Layer for the AI Era

Palantir re-imagines the warehouse as a semantic object graph:

  • Objects like Customer, Contract, Shipment are first-class citizens.
  • Relationships are explicit and navigable.
  • Metadata defines lineage, versions, and relationships between datasets.
  • Everything is composable — views, joins, and pipelines are described semantically.

Ontology effectively combines:

  • Inmon’s structure (object-based, normalized),
  • Data Vault’s historization, and
  • A semantic graph that makes relationships and lineage part of the platform.

But it comes with trade-offs: it’s powerful yet proprietary, locked inside Foundry’s platform and ontology tooling.

Model-Driven Data Engineering — The Open Middle Path

Our approach blends the best of all worlds:

This yields:

  • Business semantics like Palantir.
  • Historization and lineage like Data Vault.
  • Open, SQL-based transparency like Inmon.

All implemented through metadata, mappings, and reproducible view patterns — not proprietary black boxes.

A Real-Case Example: Customer → Account → Transaction

Let’s visualize how these models differ on the same domain.

A typical exposure view might look like:

SELECT
c.CustomerName,
a.AccountNumber,
t.Amount,
t.BusinessDate
FROM Exposure.Customer_Account_Transaction t
WHERE t.BusinessDate BETWEEN ‘2024-01-01’ AND ‘2024-12-31’;

The view itself is generated from metadata, not handwritten SQL — ensuring consistency, lineage, and auditability while staying accessible.

Recommendation

If your priority is…

  • 🏛 Enterprise semantics & governance → Inmon or Palantir Ontology
  • ⚙️ Agility & complete historization → Data Vault or Dual-SCD2
  • 🚀 Balance of both without lock-in → Model-Driven Data Engineering

Inmon gave us structure. Data Vault gave us auditability. Palantir gave us semantics.
Model-Driven Data Engineering combines all three — openly.

🧩 Key Takeaways

  • Inmon’s 3NF and Palantir’s Ontology both model business entities and history — Ontology just makes semantics explicit and navigable.
  • Data Vault formalizes historization, but often introduces unnecessary complexity.
  • Model-Driven Data Engineering achieves the same semantic richness using metadata, mappings, and bi-temporal Dual SCD2 tables.
  • The future lies in metadata-driven semantics built on open SQL foundations, not in proprietary semantic layers.

🔗 Further Reading

Part of the series: Model-Driven Data Engineering — Building a Business-Friendly, Metadata-Driven Data Platform.