OpenMetadata.

What OpenMetadata actually is

OpenMetadata is the Apache-2.0 metadata platform with the simplest operational footprint of the OSS catalogs: Postgres or MySQL plus Elasticsearch, full stop. No Kafka, no graph database, no separate ingestion service to keep alive. That choice is deliberate, and it’s the single biggest reason OpenMetadata gets adopted by teams who don’t have the platform-engineering bandwidth for DataHub.

Around that core, the project ships an unusually wide unified scope — discovery, column-level lineage, business glossary, governance workflows, data quality as code, data contracts, and collaboration — in one codebase. Connector breadth is the highest of the OSS catalogs at 120+, and the shipping cadence through 2024–2025 has been notably faster than the competition: Multi-Domain in 1.7, Data Contracts GA in 1.9, Data Quality as Code rolling out alongside.

Where it fits against the alternatives

Against datahub, the trade is architecture and shipping velocity. DataHub has the stronger SQL parser and the more event-native architecture; OpenMetadata has the simpler stack to operate and the faster governance feature cadence. Engineering-led shops tend to pick DataHub; steward-led and operationally-constrained shops tend to pick OpenMetadata.

Against atlan, OpenMetadata is the OSS counterpoint. Atlan has the more polished UX, the deeper lineage signal mix, and the bigger enterprise GTM; OpenMetadata has the open license, the simpler stack, and a credible OSS-to-managed graduation through Collate. The cost-of-ownership math usually favours OpenMetadata for teams that can self-host.

For the data-contracts story specifically, OpenMetadata’s 1.9 GA contracts feature competes directly with soda and Atlan. The trade is contract-as-code-vs-catalog: Soda’s contracts live in YAML and enforce at runtime; OpenMetadata’s contracts live in the catalog and are surfaced alongside discovery. Mature stacks pair them.

On the OpenLineage gap

The one significant interoperability hole is OpenLineage. DataHub and Atlan are both OpenLineage consumers; OpenMetadata uses its own internal lineage spec. The community has discussed adding OpenLineage support but, as of mid-2026, it is not a first-class capability. For organisations actively standardising on OpenLineage events as the metadata interchange format, this is a real consideration; for those using catalog-native lineage extraction, it doesn’t matter.

How to evaluate it

The honest test is to stand up the OSS in an afternoon — the simpler stack means this is a realistic claim — and connect three or four of your existing systems (warehouse, dbt, BI, an orchestrator) to see how the metadata, lineage, and quality features render. Look at: did the connectors pull cleanly, was the column-level lineage accurate enough to trust, and did the steward-facing UI feel usable to non-engineers? OpenMetadata’s value proposition rests on the claim that one project can credibly cover catalog plus quality plus contracts; the honest test is whether all three feel real to the people who would actually use them.