What Is a Metadata Knowledge Graph? A DataHub Definition

The honest version is that this term gets used inconsistently across the industry. Some vendors call it a metadata knowledge graph. Some call it a context graph. Some call it a knowledge graph. Some treat “active metadata” as the umbrella. The category is nascent, the vocabulary is overlapping, and there’s a commercial incentive to keep the terms fuzzy so every vendor can claim to offer one. The result is a space where people searching for the same thing land on five different definitions.

Here’s how DataHub talks about it: We use three terms: Context graph, metadata graph, and knowledge graph. “Metadata knowledge graph,” the term you probably searched for, most closely maps to what DataHub calls a context graph. This post walks through DataHub’s three-term model, explains what each one means, and makes the case for why “context graph” is the clearest name for the thing you’re most likely looking for.

What is a metadata knowledge graph, really?

A metadata knowledge graph represents a data ecosystem the way it actually works: As a web of connected data entities, not a list of isolated assets. Every dataset, pipeline, dashboard, owner, team, ML model, and business glossary term is a node. Every lineage relationship, every ownership assignment, every classification, every reference from a document to an asset is an edge.

The load-bearing word is graph. In a catalog, the underlying data structure is a table: Relationships are attributes hanging off a row, and a table has an owner field, a lineage field, a classification tag. In a graph, those relationships are the structure itself. An asset isn’t a row with a lineage column. It’s a node connected to upstream and downstream nodes through explicit edges, each of which can carry its own properties.

That shift sounds technical, but it shows up in what you can do with the data.

• A catalog answers, “Show me the rows that match this filter.”
  
• A graph answers, “Starting from this dashboard, walk backward through every pipeline and table it depends on, and tell me which ones were updated in the last six hours.”
  

The first question is a query. The second is a traversal, and traversals are what make the graph worth building.

We just spent a few paragraphs using “metadata knowledge graph” as if it were a single well-defined term. As noted above, it isn’t really. At DataHub, we use three terms for the concepts that live inside this space:

• Context graph
  
• Metadata graph
  
• Knowledge graph
  

Here’s what each one means in DataHub’s vocabulary, and where “metadata knowledge graph” fits:

Metadata graph (the baseline, technical entities only)

The metadata graph is the baseline. It’s what you get when you take the contents of a traditional data catalog and represent them as nodes and edges instead of rows and columns. Every asset, every pipeline, every owner becomes a node. Every lineage relationship, every ownership assignment, every classification becomes an edge. This is the graph that powers impact analysis, root cause analysis, and cross-system discovery.

A metadata graph is a significant step up from a catalog, but it has a ceiling. It can tell you that a metric exists, who owns it, and where it came from. It can’t tell you what the metric means, why it was defined that way, or whether it’s the right one to use for a given question.

Context graph (a.k.a. metadata knowledge graph)

The context graph is what happens when you stop treating documentation, business definitions, and institutional knowledge as separate artifacts and start treating them as nodes in the same graph as your technical metadata. A Confluence page explaining how a metric is calculated becomes a node connected to the metric. A decision log from a data governance meeting becomes a node connected to the policy it produced. The graph expands from what your data is and how it connects to what your data means and why it exists.

This is also what most people mean when they say “metadata knowledge graph.” DataHub prefers “context graph” because the load-bearing word is context: The knowledge about the data, not just the structural form of the graph. “Metadata knowledge graph” emphasizes the graph; “context graph” emphasizes what the graph carries.

For a deeper walkthrough of how context graphs work, see our post on the context graph.

Knowledge graph (same shape as a context graph, but wider scope)

Knowledge graph is the oldest of the three terms and the one with the most baggage. It comes out of the semantic web and has been used by search engines, AI researchers, and enterprise KM teams for years to describe any entity-relationship graph in any domain. That last part is the key distinction. A knowledge graph can model anything: Medical concepts, product catalogs, academic citations, or data assets. A context graph is a knowledge graph specifically scoped to a data ecosystem. Same shape, different scope.

For a head-to-head on where the two terms overlap and where they diverge, see our context graph vs. knowledge graph post.

The takeaway across all three terms: The important distinction isn’t what you call the graph. It’s what’s inside it, and whether the graph structure is the actual data model or a visualization layered on something else.

From metadata graph to context graph: The evolution

DataHub started as a metadata graph. The earliest versions modeled datasets, pipelines, dashboards, and the lineage between them. That alone was enough to make DataHub more useful than a legacy data catalog, because the graph structure made impact analysis, root cause investigation, and cross-system discovery work in ways a flat catalog schema couldn’t.

But the limits of a pure metadata graph show up quickly in practice. You can tell a user that a metric exists, who owns it, and where it came from. You can’t tell them what it means, why it was defined that way, or whether it’s the right metric for the question they’re trying to answer. Those answers live in documents, ontologies, SQL queries, decisions, Slack threads, and the heads of the people who built the thing. They’re not in the graph.

The evolution is toward a context graph: The metadata graph extended to include the external knowledge that explains the data. As DataHub ingests from 100+ data systems,documentation sources (Confluence pages, Notion docs), Context Documents, business glossary entries, and other business metadata those become nodes in the same graph as the technical metadata, connected to the assets they describe. The graph expands in scope without fragmenting in structure.

The metadata graph made DataHub a modern AI data catalog. The context graph is pushing it toward something new: A context platform.

Why context graphs matter for AI agents

The shift from metadata graph to context graph isn’t just an architectural evolution. It’s what determines whether AI agents working against your data infrastructure are reliable enough to put in front of users.

An agent reasoning over a metadata graph alone can retrieve structure. It can tell you which table holds the revenue data, which pipeline produced it, and who owns it. What it can’t do is explain what the revenue number actually represents, whether it reflects bookings or recognized revenue, or whether the definition changed in Q3 when finance updated the methodology. That information lives in documents, decisions, and definitions. If those aren’t in the graph, the agent can’t reason over them, and the answers it produces are structurally confident but semantically fragile.

A context graph closes that gap. It gives agents access to the why alongside the what: Business context like definitions, ownership history, governance decisions, and documentation that explains how a metric should be used. By connecting technical metadata to the business context around it, a context graph gives AI agents the grounding they need to produce reliable, accurate answers instead of confident guesses. It’s the difference between an agent that retrieves and one that understands.

This is where context management enters the picture.

The distinction matters. A graph that nobody maintains drifts out of sync with the organization almost immediately. Documents get stale, definitions change, ownership shifts, and the graph’s value as a source of truth erodes. Context management is what keeps the graph alive, and it’s what makes the reliability argument for AI agents hold up in production.

The DataHub State of Context Management Report 2026 surfaces the cost of not doing this well: 57% of organizations duplicate AI efforts across departments due to the lack of a comprehensive, unified context graph. That’s not a modeling problem. It’s an infrastructure and discipline problem, and it’s what a context platform exists to solve.

DataHub’s context platform, Context Documents, MCP server, and Agent Context Kit are all built against this premise: That agents reasoning over enterprise data need a context graph to work from, and that the graph needs to be maintained as shared data management infrastructure, not stitched together per use case.

What to look for in a metadata knowledge graph (and why DataHub is built this way)

If you’re evaluating a metadata knowledge graph, or a product that claims to provide one, here’s what to press on.

1. Look at how relationships are modeled

In some products, the “graph” is a visualization layer sitting on top of a legacy catalog schema, and the relationships are attributes being rendered as lines. In a real metadata knowledge graph, relationships are first-class entities with their own properties, and the graph is the data model, not the UI. DataHub was built as a graph from day one. The relationships between assets, pipelines, owners, and glossary terms are part of the underlying model, which is why traversal use cases like impact analysis and root cause work natively instead of being bolted on.

2. Look at how external knowledge enters the graph

A metadata graph that can only ingest technical metadata tops out as a better flat catalog. A context graph can ingest documents, decisions, and business knowledge as nodes in the same structure, connected to the assets they describe. DataHub’s Context Documents, business glossary, and knowledge graph features exist specifically to make external knowledge a native part of the graph rather than a linked-out afterthought.

3. Look at how AI agents interact with the graph

Retrieval-only access gives agents structure but not trust signals. What you want is programmatic access that carries ownership, lineage, governance, and provenance alongside the data itself, so both AI agents and the data engineers maintaining the graph can reason about whether to trust what they’re retrieving. DataHub’s MCP server and Agent Context Kit are built to expose the context graph to agents with those signals intact.

4. Look at whether traversal use cases work out of the box

Impact analysis, root cause analysis, and cross-system discovery across data sources are the three things a graph structure exists to enable. If they require custom queries or separate tooling, the graph isn’t doing the work it should. DataHub’s lineage, impact analysis, and cross-system discovery features all run against the same underlying graph, which means they benefit from every new node and edge the graph ingests.

Teams at Netflix, Pinterest, and Block are already using DataHub this way: As an AI data catalog where the graph carries both technical metadata and institutional knowledge, powering human discovery and agent reliability alike. It’s the difference between a legacy enterprise data catalog and the architecture AI-era data work actually needs.

FAQs