What Is OpenMetadata Used For?

Emily Winks

Data Governance Expert

Updated:08/11/2026

Published:08/11/2026

17 min read

See Context Agents Live Get the Context Layer Ebook

Key takeaways

OpenAI's internal data agent, Kepler, runs on OpenMetadata for 3,500+ employees across ~70,000 datasets.
OpenMetadata is free and Apache 2.0 licensed; Collate, its commercial backer, sells the managed version.
Most of OpenMetadata's 30 named case studies still describe classic cataloging, not AI-agent context delivery.
OpenMetadata now ships its own MCP server, but a queryable catalog still isn't the same as governed context.

What is OpenMetadata used for?

OpenMetadata is an open-source metadata platform, built and commercially backed by Collate, used for data discovery, lineage, quality testing, and governance-workflow automation across an organization's data estate. Its newest use case is serving cataloged metadata directly to AI agents through its own MCP server, most visibly in OpenAI's internal data agent, Kepler. Most of its installed base today, though, is still classic cataloging and governance work rather than AI-agent context delivery.

Where OpenMetadata is actually used today:

Discovery and lineage: search, browse, and trace data across every connected source
Data quality and governance: automated test suites and workflow-enforced data contracts
Agent access: a built-in MCP server exposes the catalog directly to AI agents
The frontier, not the median: OpenAI's Kepler runs on it, but most deployments are still classic cataloging

See if your catalog is AI-agent-ready

Check Agent Readiness

OpenMetadata is the open-source metadata platform that OpenAI’s internal data agent, Kepler, runs on to serve context across roughly 70,000 datasets to more than 3,500 employees, a build Atlan tracks closely as one read on what “AI-agent-ready” actually requires. Built by the team now running Collate, its commercial backer, OpenMetadata calls itself “the open context layer for data and AI” on its own GitHub page and now ships an MCP server for direct agent access. This page covers what it’s actually used for: discovery, lineage, quality, governance, agent access, and where a self-hosted catalog still needs more before it’s AI-agent-ready.

Most of what gets written about OpenMetadata treats it as a feature list: discovery, lineage, quality checks, governance workflows. Atlan’s own architecture walkthrough of OpenMetadata already covers that ground. The harder question is the one a team asks once an agent needs to touch the catalog: does cataloging your metadata make it usable by an agent, or just easier for a person to browse?

OpenAI’s own deployment is the sharpest current proof point. It built Kepler, its internal data agent, on OpenMetadata as the underlying catalog.
Most of the installed base is still classic cataloging. Of OpenMetadata’s 30 named case studies, only a handful mention AI or agents directly.
The newest layer is agent-facing. A recently added MCP server now exposes the catalog to agents without a person querying the UI first.
A catalog you can query still isn’t the same as context an agent can act on. That gap, not a missing feature, is where the real work happens.

Below: who built OpenMetadata, its sharpest real-world use case, how it works, the full taxonomy of what it’s used for, whether that adds up to AI-agent readiness, and how it compares to Collate.

Quick facts

Field	Detail
What it is	Open-source metadata platform, self-described on GitHub as “the open context layer for data and AI”
Built and backed by	Collate, the commercial company founded by OpenMetadata’s creators, including Suresh Srinivas
License and community	Apache 2.0; 14.8k+ GitHub stars; roughly monthly release cadence
Headline proof point	OpenAI’s internal data agent, Kepler, runs on it, serving 3,500+ employees across ~70,000 datasets
Core use cases	Data discovery, lineage, data quality testing, governance-workflow automation, MCP-enabled agent access
Deployment model	Self-hosted by default; Collate offers a managed version

What is OpenMetadata, and who’s behind it?

OpenMetadata is an open-source metadata platform, built and commercially backed by Collate, that catalogs, connects, and increasingly serves as the layer behind data discovery, governance, and AI-agent access across an organization’s data estate. It’s an Apache 2.0-licensed metadata store with connectors, a business glossary, a lineage graph, and, more recently, its own MCP server, not just a search UI sitting on top of a database.

The project was created by the team that now runs Collate, led by Suresh Srinivas, Co-Founder and CEO of Collate, formerly Chief Architect of Uber’s Data Platform and a founding engineer at Hortonworks. Srinivas has framed the project’s philosophy directly: “Let’s stop hoarding data, let’s start managing intelligence,” according to a Q&A with citybiz.

OpenMetadata’s own GitHub repository, which has grown to 14.8k+ stars behind roughly monthly releases, describes the project on its README as “The Open Context Layer for Data and AI,” a claim this page evaluates rather than accepts at face value. Two of its own first-party pages also disagree on scale: its homepage cites “4,000+ enterprise deployments,” while its dedicated case-studies page cites “3,000+.” Treat both as directional evidence of a fast-growing project, not a precise count; the two pages haven’t been reconciled publicly.

For the full architecture walkthrough, Atlan’s dedicated deep-dive on OpenMetadata’s design covers how the components fit together. This page instead focuses on what they’re actually used for, starting with the single most concrete example available right now.

What is OpenMetadata used for right now?

The single most concrete, current answer is that OpenAI built its internal AI data agent, Kepler, on top of OpenMetadata as the underlying catalog, serving more than 3,500 employees across roughly 70,000 datasets. A later VentureBeat report on the same build cites a larger figure, 4,000 employees, likely reflecting Kepler’s growth since Collate’s original case study; this page uses the more specific, dated number rather than picking one silently.

Collate’s own case study on the build is the sharpest “used for” proof point available for OpenMetadata, and it’s still under-cited by OpenMetadata’s own docs. Kepler gives OpenAI employees a self-service way to ask questions of internal data without waiting on a data team, with OpenMetadata supplying the catalog, lineage, and glossary context the agent reasons over. Atlan’s analysis of what OpenAI’s data agent reveals about enterprise AI goes deeper into the six context layers behind that build.

A second, differently-scoped deployment: Gorgias cataloged more than 45,000 data assets and built 1,400+ dbt models daily across five projects, processing more than five petabytes daily, according to OpenMetadata’s own Gorgias case study. Antoine Balliet, Senior Data Engineer at Gorgias: “OpenMetadata offers us a strong layer of discovery. It saves our data analysts a lot of time and has helped us clean up our warehouse by identifying unused models and tables.”

One quote from a third deployment is worth sitting with. Angelita Frozza Sanches, Head of Core Data Platform at Scout24, told OpenMetadata’s own case-studies team: “We all talk about AI, but the real product is not AI. Context is the real product.” She was describing her experience with a catalog tool, not making a claim about agent-readiness specifically, but a practitioner reaching for that language unprompted is a data point worth noting as this page builds toward the same distinction.

The Kepler build specifically is analyzed further in Atlan’s piece on how to build an AI agent harness; the fuller argument about what separates a catalog from AI-agent-ready context comes later in this page.

How does OpenMetadata work?

Underneath the “used for” answers above, OpenMetadata works by ingesting metadata through connectors, storing it in a searchable graph alongside a business glossary and lineage, and now exposing that graph to agents through its own MCP server.

Ingestion runs on API-based connectors that pull technical metadata from databases, warehouses, BI tools, and pipelines. A Show HN discussion from OpenMetadata’s own community found this favored over Kafka-based async ingestion by most teams, mainly for lower day-to-day operational overhead. Once ingested, that metadata sits in a graph enriched by a business glossary, where human context, definitions, ownership, tags, attaches to technical assets. Data lineage is tracked at the column level, so a change upstream can be traced to everything it touches downstream.

The newest layer is the MCP server, a recent addition exposing cataloged metadata directly to AI agents instead of requiring a person to query the UI first. Atlan’s explainer on why MCP matters for AI agents covers the broader shift: catalogs built for human search are being retrofitted with agent-facing access, one MCP server at a time, and OpenMetadata’s is a real instance of that pattern, not a marketing claim.

OpenMetadata's pipeline runs from connector to agent. What it evaluates and governs at each hop is the open question the rest of this page works through.

A well-organized pipeline still answers “how does OpenMetadata work,” not whether that work is sufficient once an agent needs context this catalog doesn’t hold, the question the next two sections take on directly.

Where does your context strategy actually stand?

Get the practical breakdown of what a real AI context stack needs beyond a catalog, in one brief.

Get the AI Context Stack

What are OpenMetadata’s core use cases?

OpenMetadata’s real-world use cases sort into five buckets, discovery, lineage, data quality, governance automation, and now agent access, and each one lands somewhere different on the distance between “cataloged” and “AI-agent-ready.”

Discovery: search and browse across every connected source, the use case most of OpenMetadata’s case studies describe first. Atlan’s own piece on enterprise search with AI covers what changes once that search interface has to serve an agent, not just a person typing a query.
Lineage: a column-level graph tracing where data comes from and where it goes, the same mechanism behind data observability for AI pipelines.
Data quality: automated test suites and alerting. OpenMetadata’s data-quality features have their own dedicated deep-dive already; Atlan’s complete guide to OpenMetadata data quality goes further than this page needs to.
Governance automation: data contracts and workflow enforcement, an actively maintained use case, not a legacy one. OpenMetadata’s 1.13.3 release notes shipped fixes to exactly this workflow layer in mid-2026, alongside alert-delivery fixes. Atlan’s own take on data contracts for AI and data mesh and AI frame why this use case matters beyond a single team’s workflow.
Agent and MCP access: the newest bucket, a live MCP server exposing the catalog to agents directly, covered in the previous section.

The table below is this page’s real payoff: not another feature list, but each use case measured against what AI-agent-ready context actually requires, the same lens Atlan’s metadata management for AI framework applies more generally.

Use case	What OpenMetadata gives you out of the box	What AI-agent-ready context still needs
Discovery	Search and browse across connected sources	Ranking and relevance tuned for agent queries, not just human search
Lineage	Column-level lineage graph	Lineage exposed in a form an agent can reason over at query time, not just a diagram a person reads
Data quality	Automated test suites and alerting	Quality signals attached to context an agent consumes before acting, not just a dashboard a person checks
Governance automation	Data contracts, workflow enforcement	Policy enforced at the point an agent requests context, per agent and per user, not just a workflow a person approves
Agent and MCP access	A live MCP server exposing the catalog	A semantics and policy layer unifying this catalog with everything else in the estate an agent also needs

Each row tells the same story: OpenMetadata gets a use case to “cataloged and queryable.” Getting the rest of the way to “an agent can safely act on this” is different work, made concrete in the next section. Teams cataloging both structured and unstructured data for AI, or connecting sources as part of a broader plan to prepare enterprise data for AI agents, run into this same gap once the catalog itself is done.

Does OpenMetadata make your data AI-agent-ready, or just easier to browse?

For most of OpenMetadata’s actual installed base today, the honest answer is “easier to browse.” The AI-agent use case is real and growing fast, but it is not yet what the majority of deployments are for.

OpenMetadata’s own case-study corpus, 30 named testimonials on its case-studies page, skews toward classic catalog and governance language: “single source of truth,” “data quality,” “discovery.” Only a handful, Scout24 and FDNY among them, mention AI or agents directly. AI-agent use is the frontier here, not the median, as of this writing.

The real cost of running it is operational, not a missing feature: self-hosted OpenMetadata means owning ingestion, uptime, upgrades, and any extension work yourself. The Show HN thread from OpenMetadata’s own community praised the team’s UI focus and active Slack support, but the DIY-ops tradeoff is the tradeoff, not a buried complaint. A r/dataengineering discussion opens with a practitioner planning exactly this kind of production deployment, framed around maintaining “a source of truth,” the same catalog-first framing dominating the broader testimonial base.

The actual gap for agent-readiness sits past the ops question and the case-study mix. OpenMetadata gives you a well-organized catalog and, now, an MCP server to expose it. A catalog you can query is not context already unified with the rest of your estate, enforced per agent and per user when it’s requested rather than granted broadly and hoped-for. That’s the distinction between a context layer and a well-built catalog, one OpenMetadata’s own “open context layer” tagline glosses over. Treating “cataloged” and “agent-ready” as the same milestone is the risk this page is pointing at, one that would show up first the moment an agent needs context from a system OpenMetadata never touched.

Not sure how big your context gap is?

Run the calculator that scores the distance between a cataloged data estate and one an AI agent can safely act on.

Run the Context Gap Calculator

Is OpenMetadata free, and what’s the difference between OpenMetadata and Collate?

OpenMetadata itself is free and open source under Apache 2.0. Collate is the commercial company, founded by OpenMetadata’s own creators, that sells a managed version so teams don’t have to run the open-source deployment themselves.

Running OpenMetadata costs nothing in license fees; what costs money is the operational effort of running it yourself, or Collate’s managed offering if a team would rather not. Suresh Srinivas, Co-Founder and CEO of Collate, frames the split directly in his own writing on why teams choose one path over the other: the open-source project stays open, and Collate exists for teams that would rather pay for someone else to operate it.

For a head-to-head against a different open-source catalog project, that’s a separate question this page doesn’t re-litigate here; Atlan’s dedicated breakdown covers that ground directly. For teams past the “should I self-host” question and ready to deploy, Atlan’s OpenMetadata setup guide picks up where this page leaves off. Either path still runs into the same agent-readiness question this page has been building toward: AI agents acting on a data catalog, or using a catalog as an LLM’s knowledge base, need more than either OpenMetadata or Collate ships on its own.

How Atlan approaches AI-agent-ready context

A catalog that’s easy to browse isn’t automatically a catalog an agent can safely act on. The gap between “cataloged” and “AI-agent-ready” from the previous section is exactly where OpenMetadata’s own use cases, real and mature as they are, stop. Technical metadata, business context, and the meaning behind terms usually live in different places, so an agent, or a person, has to assemble context by hand before it’s trustworthy.

Atlan’s Enterprise Data Graph unifies technical metadata, business context, and glossary meaning into one place people and agents both query directly. Policy context is enforced at the moment context is delivered, per agent, per user, rather than as a workflow a person signs off on separately. Lineage and certification flow into that live, queryable layer instead of sitting in documentation someone has to go find, and Atlan’s MCP server serves this governed context to agents across the estate, not just the slice one catalog covers. Atlan’s own take on semantic layers for AI agents and metadata management’s role in enterprise AI covers why that unification matters beyond any single tool.

Atlan doesn’t replace a catalog like OpenMetadata. It sits above one, turning browsable metadata into something an agent can act on safely, the shift context engineering and a properly built AI agent harness both depend on. Teams evaluating AI-ready data, or working through Context Layer 101 for the first time, land on the same question: cataloged, or ready for context-aware AI agents to use unsupervised? A catalog that never captures the tribal knowledge in people’s heads answers that honestly. Atlan’s approach to implementing an enterprise context layer for AI, and the distinction between a context graph and a knowledge graph, both pick up from where OpenMetadata’s catalog stops.

See the context layer in action

Watch how a governed context layer picks up where a self-hosted catalog stops.

Watch the Demo Series

Cataloged is not the same as AI-agent-ready

OpenMetadata’s real “used for” answer is wider than a feature list. Discovery, lineage, data quality, and governance automation are all genuinely mature, and its newest use case, serving cataloged metadata directly to AI agents through its own MCP server, is the sharpest current proof point available, anchored by OpenAI’s Kepler running on it for 3,500+ employees.

But most of its actual installed base today is still classic cataloging and governance work, not AI-agent context delivery, and self-hosting it means owning the operational cost yourself. Whether OpenMetadata is good at that classic cataloging job isn’t really the open question; its 30 named case studies answer that plainly enough. The open question is whether a browsable catalog is the same thing as context an agent can safely act on.

It isn’t, yet, by itself. That gap is where a governed context layer picks up, unifying what a catalog like OpenMetadata already does well with the business context, policy, and cross-system semantics an agent needs before it can act on any of it safely.

Check your context maturity

Score where your catalog stands on the distance from "cataloged" to "an agent can safely act on this."

Take the Maturity Assessment

FAQs about OpenMetadata

1. Is OpenMetadata free?

Yes. OpenMetadata is open source under the Apache 2.0 license, so there’s no cost to download, deploy, or modify it. What isn’t free is the operational effort: you own ingestion, uptime, upgrades, and any custom extension work. Collate, the commercial company behind OpenMetadata, sells a managed version for teams that would rather not run that operation themselves.

2. What is Collate, and how is it different from OpenMetadata?

Collate is the commercial company founded by OpenMetadata’s creators, including CEO Suresh Srinivas. OpenMetadata is the open-source project itself, free to self-host; Collate packages and manages that same technology as a hosted product, handling the infrastructure, upgrades, and support a self-hosted deployment otherwise requires you to run yourself.

3. What are the main limitations of OpenMetadata?

The biggest real cost is operational, not functional: self-hosting means you own ingestion, uptime, upgrades, and extension work. Its case-study base also skews toward classic cataloging and governance use cases rather than AI-agent context delivery, the AI-agent angle is real, it ships its own MCP server, but it’s still the frontier, not the median deployment today.

4. Does OpenMetadata support AI agents and MCP?

Yes. OpenMetadata ships its own MCP (Model Context Protocol) server, letting AI agents query cataloged metadata directly rather than requiring a person to search the UI first. The clearest proof point is OpenAI’s internal data agent, Kepler, which runs on OpenMetadata as its underlying catalog for more than 3,500 employees across roughly 70,000 datasets.

5. Is OpenMetadata the same as a data catalog?

OpenMetadata includes a data catalog, search, browse, and discovery across connected sources, but it’s broader than that: it also handles lineage, data quality testing, glossary and business context, and governance-workflow automation. Its own GitHub README calls it “the open context layer for data and AI,” a claim worth measuring against your actual AI-agent use cases rather than accepting outright.

6. Who created OpenMetadata?

OpenMetadata was created by the team that now runs Collate, its commercial backer, led by co-founder and CEO Suresh Srinivas, formerly Chief Architect of Uber’s Data Platform and a founding engineer at Hortonworks. The project is open source under Apache 2.0 and has grown to 14.8k+ GitHub stars with roughly monthly releases.

Sources

Share this article

Atlan is the context layer for AI. It gives every team and every agent the same governed, queryable context, business glossary terms, lineage, and access policy, so a catalog like OpenMetadata's isn't the last stop between your data and the AI agents that need to use it.

Book a Demo See Context Agents Live