How DataHub Integrates with Modern Data Tech Stacks
TL;DR
DataHub integration with modern tech stacks works in two directions: it continuously syncs context in from 150+ sources, and it serves that context back out to the agents, workflows, and tools that need it.
Three kinds of context come out of the systems in your stack: technical metadata, semantic context, and institutional knowledge.
Context reaches consuming tools through a hosted MCP server, a GraphQL API, and a full SDK, so agents retrieve what they need at query time rather than reasoning from raw schema.
Platform-native context layers make one vendor’s agents smarter. A context platform serves every agent in the estate from the same governed source.
For a long time, when you said “integration” with “data catalog,” it meant one thing: That a connector reached into a source system, copied metadata out, and deposited it somewhere central. More connectors meant more coverage, and more coverage meant a better catalog and better discoverability.
That definition is becoming thin now. The systems in a modern data stack hold way more than schemas. And the things consuming that information are no longer people clicking through a browser: Analytics agents query metadata programmatically, at volumes and speeds no catalog UI was designed for, and they need to know what the data means before they can use it safely.
How data catalogs have always treated integrations
In the traditional catalog model, a connector solves a plumbing problem: Build a pipe, run it on a schedule, ingest metadata like table names, column names, and data types from a warehouse, and write it into a central store.
The human user added the parts the pipe could not carry: a description of what the table is for, a note about which of the three revenue columns is the real one, a warning about the join everyone gets wrong.
That was how metadata management got scored for years: How many systems does it connect to, and how many assets can it show you? Data catalogs boasted about the number of connections they had. We did it too.
And the number of connections is still a reasonable measure because building that plumbing is a genuinely hard job: Getting metadata out of multiple systems with a dozen different APIs and into one searchable place solves a real problem for teams who had no other way to see their estate.
But it’s not sufficient because data integration alone doesn’t mean data interoperability. A predictable failure follows if you stop at integration and rely on manually created meanings: The pipes keep running. The meaning attached to what comes through it does not keep up.
Why that model breaks when agents are the consumer
A stale description is a bugbear to an analyst, who can tell something looks wrong and go ask someone. It is a different problem for an analytics agent, which cannot and will feign confidence.
Agents like Databricks Genie One and the Cortex agents behind Snowflake CoWork are now deployed across the enterprise, and they don’t fail in the way teams expect. Indeed, they rarely fail at generating SQL. They fail because they don’t know what the data means, like:
- Which table actually tracks net revenue
- How your organization defines an active customer
- Which joins your analysts validated two years ago and which ones quietly produce double-counted rows
We’ve all experienced this: Without a trusted source of context, an agent will fill the gap by inferring from what it can see, which is usually raw schema. The answer comes back fluent, formatted, and confidently wrong.
So yes, the integration piece was key, but it’s interoperability that’s now the real focus: Movement is a given. Comprehension is the part that’s still unsolved in most stacks, and why 83% of IT and data leaders say agentic AI cannot reach production value without a context platform, according to the 2026 State of Context Management Report.
An integration built for comprehension has to do three things a pipe does not:
- Sync continuously so nothing goes stale
- Capture meaning alongside structure
- Expose the result through an open interface that other systems can query
Connectors alone get you integration. They do not give you interoperability.
How DataHub builds context from your tech stack
DataHub sits between agents and your data stores as a context layer. What makes that possible is not just the number of systems it connects to, but the fact that each connection extracts three distinct kinds of context rather than one.
| Context type | What it covers | Where DataHub gets it |
| Technical metadata | Schemas, column-level data lineage, freshness, and quality signals. What exists, and whether it can be trusted | Continuously synced from 150+ sources. Lineage is parsed from warehouse query history rather than declared by hand |
| Semantic context | Business metric definitions, glossaries, and the query patterns analysts have already validated. What the data means | Ingested from dbt semantic models and BI semantic layers, and extracted from years of analyst query history |
| Institutional knowledge | Documentation, runbooks, and decisions that explain why a dataset exists and how it should be used | Ingested from Confluence, Notion, and GitHub, then chunked, embedded, and connected to the assets it describes |
1. Technical metadata
This is the layer most catalogs stop at, and DataHub goes further into it than a scheduled schema crawl allows. Schemas, lineage, freshness, and quality signals sync continuously from 150+ sources, so the picture reflects the estate as it is rather than as it was at the last refresh.
Lineage is the clearest example of the difference. Rather than asking teams to declare dependencies by hand, DataHub derives column-level lineage by parsing query history from the warehouse. The transformations your pipelines actually ran are the source of truth, not a diagram someone drew during onboarding.
2. Semantic context
Technical metadata tells an agent what exists. Semantic context tells it what the data means, and it comes from two places your stack already holds.
- The definitions your teams already maintain. Business metric definitions and glossaries are ingested from dbt semantic models, Looker’s LookML semantic layer, Tableau published data sources, and Power BI semantic models. These represent real organizational investment in defining meaning precisely, so DataHub treats them as authoritative input rather than raw material.
- The queries your analysts already run. Validated query patterns are extracted from years of query history. How analysts filter, join, and aggregate encodes business logic that nobody ever wrote down, and mining it surfaces that logic without a documentation project.
That second point matters most for teams starting from nothing: The cold-start problem, where a context initiative stalls because there is no documentation to build on, is answered by the query history you already have.
3. Institutional knowledge
The context that explains why a dataset exists rarely lives in the dataset. It lives in a Confluence page, a Notion doc, a runbook in a GitHub repo, written by someone who understood the decision at the time.
DataHub ingests those sources, chunks and embeds the content, and connects each piece to the assets it describes. They are treated as first-class semantic sources rather than attachments, which is what turns a wiki page from something a person might eventually find into context an agent can retrieve at the moment it is needed.
That institutional knowledge was in people’s heads. Get it out into DataHub and it becomes much more accessible.
David WalkerStaff Engineer, Trustpilot
DataHub’s integrations: A high-level overview
DataHub ships connectors for 150+ systems. We’re not going to list them all here (there’s a page for that). But here’s an overview of what each category of your stack contributes to the context graph.
| Category | What DataHub extracts | Examples |
| Data warehouses | Schemas, ownership, usage statistics, and column-level lineage parsed from query history |
|
| Cloud platform services | Bucket contents with inferred schemas, catalog table schemas, and pipeline metadata and lineage |
|
| BI and analytics tools | Chart and dashboard metadata, published data sources, and the link from each report back to its warehouse tables |
|
| Transformation and pipeline tools | Models, tests, sources, and exposures with column-level lineage, plus DAG-level lineage captured as pipelines run |
|
| ML platforms | Models, experiments, feature views, and entities, with lineage from raw sources through to ML features |
|
| Data quality platforms | Freshness, volume, and schema anomaly alerts, plus validation results, surfaced on the table pages themselves |
|
| Streaming and messaging | Topic schemas from the schema registry, which is what makes lineage possible for real-time pipelines |
|
| Operational databases | Schemas and lineage from the upstream OLTP systems feeding your ELT pipelines |
|
| Unstructured and knowledge sources | Documentation chunked, embedded, and connected to the data assets it describes |
|
Worth noting: The transformation and pipeline tools are the most valuable integrations for lineage, because they record how each metric and column was actually derived, and dbt with DataHub is one of the most common integration pairs in enterprise data teams. Kafka matters for a different reason, since topic schemas are what extend lineage into real-time pipelines rather than leaving it to batch.
DataHub is also a member of Open Semantic Interchange, the emerging framework for semantic interoperability across platforms, and works with ClickHouse through a dedicated partnership.
If you’re curious about anything not named here, the Integrations page carries the full and most current list.
How context travels between the tools on your tech stack
Ingestion is half of an integration. The other half is whether anything can get the context back out.
Context in DataHub is exposed through:
Any agent that speaks Model Context Protocol can retrieve context directly. Data governance workflows, downstream systems, and internal applications can query the graph programmatically through GraphQL and the SDK.
The practical effect is that an agent asks for precisely the context a question requires, at the moment the question arrives, rather than reasoning from raw schema with metaphorically crossed fingers. An agent answering a revenue question can retrieve the metric definition, the lineage behind it, the freshness of the underlying table, and the caveat someone documented in Confluence, in one step.
This is also where a context platform differs from the context layers the platforms themselves are building. Snowflake Cortex Sense and Databricks Genie Ontology both assemble business context and serve it well, and both serve it to their own vendor’s agents. Context built for one platform’s agents is additive to that platform and portable to no other, which leaves you with fragmented systems of meaning rather than one. A context platform sits underneath all of them and serves the same governed context to every agent, wherever it runs.
Making it real: The difference that true interoperability makes
Integration moves metadata between systems. Interoperability means the meaning arrives with it and stays usable wherever the question gets asked. The difference is invisible in an architecture diagram and obvious in the day-to-day work.
Analytics agents that answer correctly
When an agent needs to find the relevant datasets for a question, and to know what their columns mean, who owns them, and whether they are reliable, it queries DataHub instead of guessing. Miro reports text-to-SQL accuracy improving from around 50% to over 90% after adding DataHub as its context layer.
Pinterest powers its in-house analytics agents the same way, and FIS grounds Databricks Genie in enterprise context through DataHub Cloud.
Lineage that survives the handoffs between tools
Connect DataHub to Snowflake, dbt, Airflow, and Looker (a very common enterprise combination) and the result is an unbroken lineage graph that follows the data flow from raw source table to finished dashboard. An analyst can open a report, trace it back through the dbt transformations that shaped it, through the Airflow runs that scheduled them, to the Snowflake or S3 table it started in, in clicks rather than days.
That matters most on those days when a number looks wrong:
- Without a connected graph, the team reconstructs the path by hand, reading SQL and asking whoever built the pipeline what it was supposed to do
- With one, they pinpoint the transformation that introduced the problem and see everything downstream that inherited it
The mechanics of this are covered in our guide to end-to-end data lineage.
Quality status where people look for data
Quality signals are usually stranded in the tool that produced them, which means the person deciding whether to use a table is not the person who can see whether it is healthy. DataHub surfaces those alerts on the table pages themselves, so schema, lineage, documentation, and the most recent quality result arrive together.
Super Technologies runs Snowflake and DataHub together for end-to-end data quality monitoring, with freshness and volume anomaly alerts surfacing on the relevant Snowflake table pages in DataHub. The answer to “can I trust this?” stops being a ticket and becomes something a data consumer can settle for themselves.
Data discovery and ML governance without the tool-hopping
With connectors across every major warehouse and 15+ BI tools, analysts and data engineers get one searchable interface across the entire data ecosystem, instead of logging into Looker, then Tableau, then the warehouse, then a Notion doc. Trustpilot describes the shift as a change in default behavior, where teams now ask whether something is in DataHub before routing the question to a person.
Through MLflow and Feast, ML engineers get a verifiable record of which datasets trained which models, and which raw sources produced the features underneath them. That record is increasingly an audit requirement rather than an internal convenience, as AI governance practices and frameworks mature and organizations are asked to show their working.
So, in summary: Yes, connector counts are a starting condition. But they’re no longer a sufficient differentiator. Every serious platform in this category connects to the systems you run, so integrated data is the baseline rather than the edge. The question is what each connection actually pulls out, and whether anything else in your stack can reach it afterward. Context that only one vendor’s agents can consume becomes another silo, and silos are the problem context platforms exist to solve.
