Technology

OpenMetadata

An open-source metadata platform providing a centralized catalog for data discovery, quality, lineage, and governance across S3-based data lakes and lakehouses.

9 connections3 resources1 post

Summary

What it is

An open-source metadata platform providing a centralized catalog for data discovery, quality, lineage, and governance across S3-based data lakes and lakehouses.

Where it fits

OpenMetadata sits in the governance and discovery layer above S3 storage and query engines. It ingests metadata from Iceberg tables, Spark jobs, Airflow DAGs, and other tools to provide a unified view of what data exists, who owns it, and how it flows through the organization.

Misconceptions / Traps

OpenMetadata is a metadata platform, not a query engine or catalog. It discovers and displays metadata from external systems (Glue, HMS, Iceberg catalogs) but does not replace them.
Data quality checks in OpenMetadata require configuring profiler workflows. The platform does not automatically validate data without explicit setup.
Deploying OpenMetadata requires running its own backend services (API server, database, Airflow for ingestion). It is not a lightweight tool.

Key Connections

scoped_to Metadata Management — centralized metadata discovery and governance
enables Audit Trails — tracks metadata change history
alternative_to DataHub, Apache Atlas — open-source metadata platform alternatives
depends_on AWS Glue Catalog, Hive Metastore — ingests metadata from catalogs

Definition

What it is

An open-source metadata platform that provides data discovery, lineage, quality, and governance for S3-based data lakes and lakehouses. Ingests metadata from catalogs, query engines, and pipelines to build a unified metadata graph.

Why it exists

As data lakes grow, teams lose track of what data exists, where it came from, who owns it, and whether it is trustworthy. OpenMetadata centralizes this information with automated metadata ingestion from S3-based sources.

Primary use cases

Data discovery and cataloging for S3 lakehouses, automated lineage tracking, data quality monitoring, governance and ownership management.

Recent developments

Latest signals

Latest release: 2.0.2 (September 16, 2026) — the catalog rebrands itself as a context layer for agents. OpenMetadata 2.0 formally drops the "data catalog" category and positions as "The Open Context Layer for Data and AI", per the project README and the 2.0 release notes. The architecture is reoriented around machine consumers rather than human browsers: a semantic context graph with RDF support turns the metadata store into a traversable network, and the Model Context Protocol is enabled by default, exposing the catalog as a set of callable tools so an agent can run semantic search, walk lineage, and mutate metadata at query time. A new AI Studio and Context Center ingest unstructured operational documents — runbooks, wiki pages — directly into the metadata graph and attach hybrid vector + keyword search to individual data assets. This is the convergence the Catalog-Centric Control Plane node tracks, arriving from the metadata side rather than the table-format side. On the prior line, 1.13.3 shipped August 2026 and 1.13.0 (GA June 8, 2026) added MCP Services as a first-class service category plus Knowledge Graph / RDF support; as of August 2026, 1.12.x remained a maintained patch line for teams not yet on 1.13.
The 1.13 → 2.0 migration is genuinely breaking — back up first, because there is no downgrade. Per the official breaking-changes overview and OpenMetadata Standards, operators are instructed to take a full database backup before migrating: the 2.0.0 script creates 15+ new tables, renames thread_entity, and rewrites application, service-connection, and tag rows in place, with no automated rollback path. Four further changes bite in production — the Airflow-based internal orchestrator is deprecated in favour of the native Kubernetes Orchestrator introduced in 1.12 (Airflow still runs in 2.0, but is on notice); the thread-backed collaboration model is rewritten onto a new Tasks entity, with the /v1/suggestions endpoint removed outright; embedding and natural-language-query settings move out of the elasticsearch.naturalLanguageSearch block into a dedicated llmConfiguration block; and custom ingestion images must be rebuilt against Python 3.12, because CP310 binary wheels fail to import on the new base image. Anyone running pinned ingestion containers should budget this as a rebuild, not an upgrade.
2.0 chose interoperability with rival catalogs over competing with them. The release shipped a Unity Catalog model-version resolution fix and a native Apache Polaris credential-vending record, per the 2.0 release notes — but it does not ship a native Iceberg REST catalog surface of its own. The posture is defensive bridging: sit semantically above Unity Catalog, Apache Polaris and Apache Gravitino rather than replace them. For the Catalog-Centric Control Plane question that is a data point against near-term consolidation on any single control plane — the metadata layer is betting the catalog war stays unresolved long enough for a semantic layer to be worth buying.
Operational metrics: 94.7% issue-resolution rate, 0.9-hour median PR merge time. Per a 2026 OpenMetadata project-health review, the team posts a 94.7% issue resolution rate and a 0.9-hour median PR merge time. For organizations evaluating community responsiveness as a procurement criterion, these are unusually fast numbers — and they map onto the "younger but actively maintained" framing that OpenMetadata occupies vs the older DataHub project (which has 11,600+ stars and a three-year head start on forks: 3,457 vs OpenMetadata's lower count).
Honest caveats from independent reviews. Per a 2026 OpenMetadata open-source data-catalog review, the main operational caveat is UI performance at scale — lineage graphs with 500+ nodes can become slow to render in browser. Also flagged: less battle-tested at extreme scale relative to DataHub. Decision framing for 2026: OpenMetadata wins on developer velocity and recent-feature-investment; DataHub wins on production-tested-at-scale references.
A critical auth-bypass (CVE-2026-26010) leaked ingestion-bot JWTs via /api/v1/ingestionPipelines, letting any authenticated user impersonate the ingestion service; patched in 1.11.8. Per CVE-2026-26010 — SentinelOne Vulnerability Database.
April 2026: GitHub Trending #1 globally, Linux Foundation membership, and OSI standard adoption for OpenMetadata Standards v1.13 capped a six-month momentum run that also included the Metadata AI SDK and MCP server. Per Pebblous — OpenMetadata Completes the AI Ready Data Stack.
A published EKS benchmark against 2M assets and 5.8M tags (15M+ relations) held GET under 400ms and PATCH under 600ms at up to 1,000 concurrent Locust users, with zero failed requests — a concrete scale data point against the "less battle-tested than DataHub at extreme scale" caveat already noted. Per OpenMetadata — Supporting Millions of Data Assets & Relations.
Data contracts (introduced in 1.8) gained catalog-scheduled enforcement after ingestion as of 1.10+, positioning OpenMetadata as one of three viable data-contract enforcement layers alongside shift-left tools (datacontract-cli) and streaming enforcement (Redpanda/Confluent). Tertiary source. Per Zircote — Most Data Contract Tools Don't Enforce Contracts.