In the two previous articles we explained what data governance is and its three pillars: catalog, lineage, and quality. The next question is what you build that with in practice. In this article we introduce OpenMetadata, the open source platform that in just a few years became the reference in its category. An important clarification: this is an educational article. OpenMetadata is open source and free — nobody pays us to talk about it. It is the platform we use to illustrate these concepts because it is open, anyone can try it for free, and it reflects the state of the art well.
The problem: metadata scattered everywhere
Metadata is the data about your data: which tables exist, what their columns mean, who owns them, where they come from, how fresh they are. Historically, that information lived scattered: the data dictionary in an Excel file (outdated), business definitions in a wiki (even more outdated), lineage in the heads of two engineers, and quality tests — if they existed at all — in loose scripts.
The first generation of tools attacked the problem piece by piece: a catalog here, a lineage tool there, another one for quality. The result was ironic: to solve data silos, we created metadata silos. The catalog said one thing, the quality tool another, and keeping them in sync was a project in itself.
What is OpenMetadata?
OpenMetadata is an open source metadata management platform that unifies the pillars of data governance in one place: discovery and catalog, lineage, data quality, business glossary, sensitive data classification, and collaboration. It emerged in 2021, created by engineers who lived these problems at scale (part of the founding team built data infrastructure at companies like Uber), and it is published under the Apache 2.0 license — free to use, inspect, and modify.
Its central idea is simple but powerful: an open metadata standard. Instead of every tool inventing its own format, OpenMetadata defines open, versioned schemas for each asset type (tables, dashboards, pipelines, ML models, metrics) and an API on which everything else is built. Its connectors — more than 80 of them — automatically extract metadata from the sources: warehouses like BigQuery or Snowflake, databases like PostgreSQL or MySQL, BI tools like Power BI or Tableau, orchestrators like Airflow.
What it looks like in practice
For anyone who has never seen a platform of this kind, the most illustrative thing is the typical user journey:
- Search. You type "churn" in the search bar and get ranked results of tables, dashboards, and metrics, with trust signals: owner, description, tags, last update.
- Understand. A table page shows its schema with per-column descriptions, its owner, its certification tier, sensitive data tags (PII), and a data sample if you have permission.
- Trace. The lineage tab draws the full graph: which pipelines the table comes from, which transformations produce it, and which dashboards depend on it — the dependency map we covered in the previous article, generated automatically.
- Trust. The quality tab shows the tests defined on the table (freshness, nulls, duplicates, ranges) and their history: green, green, green, red last Tuesday — with the incident and who handled it.
- Align. The business glossary defines the official terms ("active customer", "recurring revenue") and links them to the tables and columns that implement them.
Why did it become the open source standard?
- It unifies what used to be three or four tools. Catalog, lineage, quality, and glossary share the same data model. There is no synchronization between silos because there are no silos.
- The standard is genuinely open. The metadata schemas are public, versioned specifications, and the entire platform is operated via API. Your metadata is not held hostage by a proprietary format: it goes in and out whenever you want.
- Apache 2.0 license with no surprises. The code is on GitHub, the community is active, and the release cadence is steady.
- Connector coverage. More than 80 native integrations means that, in most modern stacks, metadata starts flowing from day one, without custom development.
For historical context: it was not the first. Pioneering projects like Amundsen (Lyft) and Apache Atlas paved the way, and DataHub (LinkedIn) remains a solid alternative. But OpenMetadata was born later, with the lesson learned: instead of being "a catalog with extras", it was designed from scratch as a unified platform on top of an open standard — and that architectural bet is the one the community ended up validating.
What OpenMetadata will not do for you
Here is the part no vendor tells you and that we care to underline: installing a tool is not doing data governance. OpenMetadata grounds the agreements, but the agreements must be made by your organization: who owns what, which definitions are official, what quality threshold is acceptable. A platform with an empty catalog and ownerless tables is just one more unused tool.
Our usual recommendation applies: start with the critical assets, assign real owners, and let the tool do what people cannot — automate the inventory, draw the lineage, and watch quality around the clock.
If you want to explore it
You can get to know OpenMetadata without installing anything: the official documentation lives at open-metadata.org and the project maintains a public sandbox to explore the interface with sample data. If you prefer to run it on your own machine, the Docker deployment guide is in that same documentation and takes a few minutes on a reasonable laptop. And if you want to see a concrete use case with real screenshots, we show you how to create your first data quality rule step by step.
Data governance is decided in the agreements and sustained by the tools. OpenMetadata is, today, the best open source expression of that second half.
If your organization is evaluating this step, see how we approach OpenMetadata implementation — or start further back, with a data maturity assessment.