When to choose OpenMetadata or DataHub for your metadata catalog
Choose OpenMetadata when you want a catalog whose core services are a single server, a relational database, a search engine and Airflow for metadata ingestion, and your team already runs Airflow or is comfortable adding it. Its bare metal requirements (Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, Elasticsearch 9.x or OpenSearch 3.x, and Airflow for ingestion) describe a stack most platform teams can map to existing skills. Confirm that your Airflow version is supported, since Airflow 2 reached end of life on April 22, 2026, and that the OpenMetadata release you plan to run documents the same versions in the OpenMetadata bare metal guide.
Choose DataHub when your organization already operates Kafka and has engineers who can run it, and when you want metadata changes streamed as events rather than collected on a schedule. DataHub's architecture centers on a metadata service (GMS) with Kafka for streaming metadata changes, MySQL or PostgreSQL storage, Elasticsearch or OpenSearch search, and both push and pull ingestion. Push ingestion suits source systems that can emit their own change events. Pull ingestion suits sources you cannot change. Confirm which of these your sources support before you commit to a design.
Four drivers should settle the choice: the stack you already run (Airflow or Kafka), the ingestion model your sources support (scheduled pulls, pushed events or both), the governance depth you need on day one, and who will operate the platform after go-live. Ask each candidate for a written list of the components that must stay healthy and the upgrade path for each. Your operators, not the feature list, will carry most of the long-term cost.
Which scenarios favor OpenMetadata and which favor DataHub
This table maps common team situations to the platform that usually fits better and the condition that makes it so. Read each row as a starting point, then confirm the condition against your own estimate of Airflow, Kafka and platform staffing before deciding.
| Scenario | Better fit | Condition that makes it so |
|---|---|---|
| Existing Apache Airflow estate running production pipelines | OpenMetadata | OpenMetadata runs metadata ingestion through Airflow, so the team already operates the scheduler it needs. Confirm that your Airflow version is supported by the OpenMetadata release you plan to deploy. |
| Organization already running Kafka as a core event backbone | DataHub | DataHub's architecture centers on Kafka for streaming metadata changes, so the team can reuse existing Kafka operations skills. Confirm capacity and retention settings with your platform team before adding metadata topics. |
| Small team with limited platform capacity | OpenMetadata | Fewer moving parts is the main argument: OpenMetadata's bare metal requirements list a Java 21 server, a database, a search engine and Airflow, with no Kafka layer. Ask DeployOpen or the vendor to list every component your chosen deployment method needs. |
| Need for push-based change capture from source systems | DataHub | DataHub supports both push and pull ingestion, so sources that can emit changes can send them directly. Confirm which of your sources support push and whether your team will maintain the emitters. |
| Need for pull-based scheduled crawling of many sources | OpenMetadata | OpenMetadata's ingestion is built around scheduled connectors run through Airflow. This fits teams that want predictable crawls on a schedule. Confirm connector coverage for your specific source systems. |
| Mixed push and pull requirements across many teams | DataHub | Supporting both ingestion models in one platform can reduce the need for separate tooling. This matters only if your teams truly need both patterns, so confirm the connectors you depend on. |
| Strict data residency with no external orchestration allowed | Depends on the deployment | Both platforms are self-hosted Apache-2.0 projects, so residency is set by where you deploy. Confirm which components your security team will approve, especially Airflow for OpenMetadata or Kafka for DataHub. |
How OpenMetadata and DataHub are built and what that means for operations
Both catalogs are Apache-2.0 and both depend on a relational database and a search engine, but they reach those pieces differently. OpenMetadata centers on one server with Airflow handling ingestion, while DataHub adds Kafka to stream metadata changes through its metadata service. Each added system is one more thing to patch, monitor, size and back up.
OpenMetadata server and Java 21
OpenMetadata runs as a Java application that requires Java 21 on bare metal. Your team owns the JVM version, its patch cadence and the process that restarts the server after a failure. Check whether your platform standard already supports Java 21 and who signs off on runtime upgrades. Ask DeployOpen to document the service layout, startup order and rollback steps in the runbook before go-live.
OpenMetadata relational database
OpenMetadata stores its core metadata in MySQL 8.0.42 or later, or in PostgreSQL 15 or later. This database is the system of record, so its backup, restore testing and version lifecycle become your responsibility. Confirm which engine your database team already operates and how point-in-time recovery is tested. If you choose PostgreSQL, check that your version lifecycle matches the release you deploy.
OpenMetadata search tier
OpenMetadata uses Elasticsearch 9.x or OpenSearch 3.x for search. Search indexes are rebuildable from the database, but reindexing a large catalog takes time and capacity, so plan for it during upgrades. Confirm whether your organization already licenses and patches one of these engines, and ask who owns index sizing and cluster health alerts.
OpenMetadata Airflow ingestion
Metadata ingestion in OpenMetadata runs through Airflow, so an Airflow deployment becomes part of the catalog's operating footprint. If you already run Airflow for pipelines, the catalog can share that estate, but its scheduler load and upgrade path then affect both. Airflow 2 reached end of life on April 22, 2026, so confirm which Airflow line your ingestion will use before you build connectors.
DataHub metadata service (GMS)
DataHub's metadata service, GMS, is the central API that reads and writes metadata for the platform. It is the component your teams call directly and the one that needs capacity planning for concurrent writes from many ingestion sources. Ask DeployOpen to confirm GMS sizing, health checks and how it is upgraded alongside its frontend and ingestion containers in your environment.
DataHub Kafka streaming layer
DataHub uses Kafka to stream metadata changes between its components. Kafka adds a broker cluster, topic configuration, consumer lag monitoring and retention settings that must be backed up or recreated after a loss. If your organization already runs a managed or internally supported Kafka platform, this may be a manageable addition. If not, count it as a new system with its own on-call burden and security review.
DataHub storage and search
DataHub stores metadata in MySQL or PostgreSQL and indexes it in Elasticsearch or OpenSearch. Those two systems carry the same backup, version and capacity duties as in any catalog, and the Kafka layer adds a third stateful path that must stay consistent with them. Confirm which database and search engine versions your DataHub release supports before you commit to a stack, and test recovery of all three components together.
Ingestion model and push versus pull
DataHub supports both push and pull ingestion, which means some sources can send metadata to the platform while others are pulled on a schedule. Pull ingestion keeps a scheduler in your operating model, and push ingestion moves that responsibility to the source system's pipeline. Map each source you need to the ingestion mode it supports, and decide who owns credentials and failure alerts for each connector.
Capability comparison for governance, identity and extensibility
This table sets OpenMetadata and DataHub side by side on licensing, release lines, storage, search, ingestion and deployment prerequisites. Treat the version and dependency rows as facts to plan against, and treat the governance rows as questions to confirm in each vendor's documentation. The main takeaway is that both are Apache-2.0 and differ mainly in runtime shape: a Java server that relies on Airflow for ingestion versus a Kafka-based streaming design.
| Capability | OpenMetadata | DataHub |
|---|---|---|
| License | Apache-2.0 | Apache-2.0 |
| Current release line | 2.0 line, with 2.0.5 released October 8, 2026 | v1.6.0.3 released September 25, 2026, with v1.8.0 release candidates following |
| Core runtime | Java 21 on bare metal, with a metadata server backed by a database | Metadata service (GMS) with Kafka streaming metadata changes |
| Storage backend | MySQL 8.0.42 or later, or PostgreSQL 15 or later | MySQL or PostgreSQL storage |
| Search backend | Elasticsearch 9.x or OpenSearch 3.x | Elasticsearch or OpenSearch |
| Ingestion model | Metadata ingestion runs through Airflow, so plan for an Airflow version that is still supported | Both push and pull ingestion, with Kafka carrying changes |
| Lineage, access control and SSO | Not established in supplied facts; confirm in OpenMetadata documentation | Not established in supplied facts; confirm in DataHub documentation |
| Operating components to run | Server, database, search cluster and Airflow for ingestion | Metadata service, Kafka, database, search cluster and ingestion sources |
What is free and what is paid in each catalog
OpenMetadata is licensed under Apache-2.0, so its server, ingestion framework and documented deployment path can be run in your own environment without a license fee to the project. The license governs use and redistribution of the code. It does not cover the infrastructure you run the platform on, the components it depends on, or the people who operate it.
- Software license: Apache-2.0 permits commercial use, modification and redistribution, subject to its notice requirements.
- Required components: The bare metal requirements include Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, Elasticsearch 9.x or OpenSearch 3.x, and Airflow for metadata ingestion. Each one carries its own license terms and hosting cost that you need to check.
- Current line: The 2.0 line is current, with 2.0.5 released on October 8, 2026, according to the project's release page.
- Operating labor: Upgrades, backups and search reindexing fall to your internal team or to a services partner you engage.
Check the bare metal deployment page against the versions you plan to run before you budget infrastructure, since the dependency list determines most of the hosting spend.
DataHub is also licensed under Apache-2.0, so the code carries the same permissive terms as OpenMetadata. The difference in running cost comes from architecture. DataHub centers on a metadata service that uses Kafka to stream metadata changes, backed by MySQL or PostgreSQL storage and Elasticsearch or OpenSearch search. Those extra moving parts are where most of the planning effort sits.
- Software license: Apache-2.0 covers the DataHub code, so the license question is the same as for OpenMetadata.
- Streaming layer: Kafka is an additional component to host, secure, patch and monitor. Confirm its licensing and which distribution your team would use.
- Current release: v1.6.0.3 was released on September 25, 2026, and v1.8.0 release candidates followed, according to the project's release page.
- Storage and search: The relational database and search engine choices overlap with OpenMetadata, so a team already running those services may reuse existing skills and tooling.
Ask which Kafka version and distribution your team would run, because that choice drives support, patching and monitoring work for the life of the deployment.
Both projects are open source, and this page does not identify a commercial edition, hosted service or paid feature tier for either OpenMetadata or DataHub. Treat the existence and contents of any paid offering as an open question to settle with each vendor before you choose a platform. Do not assume that the open-source distribution includes every feature that a governance program will need.
- Hosted offers: Ask whether each project's company offers a managed deployment, and what it covers for upgrades, backups, monitoring and support.
- Enterprise features: Ask which identity integration, access control, audit and governance features ship in the open-source distribution and which require a paid edition.
- Support terms: Ask for response targets, severity definitions and the process for patching security advisories, and get the answers in writing.
- Included components: Confirm in writing which components, connectors and documentation are covered for the exact version you plan to run.
Confirm each answer against current vendor material on the date of your quote, because editions, feature lists and support terms change over time.
Even with no license fee, a self-hosted catalog creates costs that recur for as long as it runs. They fall into infrastructure, staff time and external support. One-time costs usually include planning, connector setup, identity integration and the first round of hardening. The recurring share typically grows with metadata volume, the number of connectors and the number of teams that depend on the catalog.
- Infrastructure: Databases, search clusters and, for DataHub, a Kafka cluster must be sized, hosted and kept available. Storage and compute scale with the metadata you ingest.
- Orchestration: OpenMetadata runs ingestion through Airflow, so the upkeep of that scheduler belongs in the total cost, even if another team already operates it.
- Upgrades: Each release line needs regression testing against your connectors, identity setup and any custom code before it reaches production.
- Services: Implementation, hardening, documentation and retainer support are priced from a written scope, since DeployOpen does not publish a price list.
Ask any partner for a quote that separates one-time setup from recurring hosting, staffing and support, so you can compare the two products on the same basis.
What drives the running cost of each catalog
Both catalogs are self-hosted, so the bill is mostly infrastructure, skilled labor and upkeep rather than license fees. The cards below separate what is set up once from what recurs every year, and list what to request in a written scope before comparing quotes.
Metadata database and search cluster
OpenMetadata needs MySQL 8.0.42 or later or PostgreSQL 15 or later, plus Elasticsearch 9.x or OpenSearch 3.x for search. DataHub also uses MySQL or PostgreSQL and Elasticsearch or OpenSearch, so both carry this recurring hosting cost. Ask the quote to size the database and search nodes for your entity count, backup retention and high availability, and to state which of these run in your own cloud account or data center.
Kafka streaming infrastructure
DataHub's architecture centers on Kafka for streaming metadata changes, so a Kafka cluster is a recurring component that OpenMetadata does not require. Kafka adds broker capacity, storage, monitoring and patching to someone's queue. Ask whether the scope includes a managed or self-hosted Kafka, who owns its upgrades, and how broker sizing changes as ingestion volume grows.
Airflow capacity for ingestion
OpenMetadata runs metadata ingestion through Airflow, so the scheduler, workers and their storage are a recurring cost unless you already operate Airflow. Airflow 2 reached end of life on April 22, 2026, so an existing Airflow 2 estate may need an upgrade before it can carry ingestion. Confirm the Airflow version in scope, who maintains it, and whether the quote covers that upgrade.
Skilled engineering time
Both platforms need people who understand Java services, the search index, the metadata store and the ingestion pipelines. This is usually the largest recurring cost, whether paid through internal salaries or an implementation partner. Ask who will operate each component after handover, what skills the handover covers, and how many hours of ongoing administration the quote assumes for each month.
Version upgrades and patching
Both projects release often: OpenMetadata's current line is 2.0, and DataHub v1.6.0.3 was released on September 25, 2026, with v1.8.0 release candidates following. Each upgrade touches the server, the ingestion framework, the search index and, for DataHub, the Kafka layer. Ask the quote to state the upgrade cadence it covers, how a rollback is tested, and whether upgrades are priced per release or in a retainer.
Support, retainers and one-time setup
Implementation, integration with identity and data sources, hardening and documentation are typically one-time work agreed in a fixed scope. Ongoing support, upgrades and testing are usually a separate recurring retainer. Ask the quote to split these into one-time and recurring lines, name the response expectations in writing, and confirm what happens to the retainer if the platform version changes mid-contract.
Moving a catalog from one platform to the other
This sequence moves a working metadata catalog from OpenMetadata to DataHub, or the reverse, without a cutover gap. It separates what can be carried across as definitions from what must be rebuilt in the target's ingestion model, and it ends with a validated switch that teams can roll back if counts or ownership disagree.
Inventory sources and ingestion pipelines
The platform team lists every source system, its connection settings, its ingestion schedule, and the code or Airflow DAG that runs each pipeline today. Owners of each source confirm which pipelines are still in use and which are stale. The output is a written inventory with one row per source, showing the connector type, the owner, the schedule, and whether it runs on Airflow or on another trigger. The step is done when the source owners have signed off on the list.
Map metadata entities and ownership
The team maps each entity type in the source catalog, such as databases, tables, dashboards, pipelines, glossary terms, tags, domains, and owners, to the equivalent model in the target platform. Anything without a direct match is recorded as a gap with a decision about whether to drop it, store it as a tag, or model it differently. Ownership and team assignments are mapped explicitly, since these are the fields that data stewards check first after a move. The step is done when every entity type has a mapping and the gaps have named decision owners.
Confirm what the vendors can export
Before building anything, the team asks each vendor, in writing, which metadata exports, API reads, or bulk dump options are supported for the installed version, and whether lineage, glossary links, and access policies come along. The answers are checked against the exact release in use, not the latest documentation. Transfer assumptions that the vendor cannot confirm are treated as rebuild work. The step is done when the export capabilities are documented and accepted by the platform owner.
Rebuild ingestion in the target model
Source connections and metadata definitions are carried over in principle, but the ingestion logic is rebuilt. In an OpenMetadata to DataHub move, Airflow-driven ingestion is replaced with DataHub's push and pull ingestion. In a DataHub to OpenMetadata move, the Kafka-based change flow is replaced with the ingestion framework that OpenMetadata runs through Airflow. Each rebuilt pipeline is tested against a non-production copy of its source. The output is a passing run per source, with the entity counts recorded beside those from the old platform.
Run both catalogs in parallel
Both platforms ingest the same sources for a validation period agreed in the project plan. Data stewards compare entity counts, owners, descriptions, tags, and lineage edges for a sample of high-use assets. Search results are compared for the terms that business users rely on most. Differences are logged with a cause and an owner. The step is done when the agreed comparison checks pass or each remaining difference has an accepted explanation.
Rehearse the cutover and rollback
The team runs a full cutover rehearsal on a copy of the production environment. This includes switching consumer links, access groups, bookmarks, and any API clients that read the catalog, and then reversing those changes. The rollback path is timed and documented so the team knows how long reverting takes. The step is done when the rehearsal completes both directions and the runbook has been reviewed by the operations owner.
Cut over and retire the old catalog
The team switches users, integrations, and scheduled ingestion to the target platform during a change window approved by the business owners. The old ingestion jobs are paused first, then removed once the new ones have run cleanly. The old platform is kept read-only for an agreed retention period so that audit questions can be answered. The step is done when all consumers point to the new catalog, the old pipelines are stopped, and the retention decision is recorded.
Where OpenMetadata and DataHub implementations usually run long
The slow parts are rarely the first install. Both platforms can be stood up quickly in a lab, but a production rollout spans several separate workstreams: provisioning the stack, connecting sources, setting ingestion schedules, configuring access and identity, and onboarding stewards who will maintain descriptions, owners and classifications. For OpenMetadata, provisioning means a Java 21 server, a MySQL or PostgreSQL database, Elasticsearch or OpenSearch for search, and an Airflow deployment that runs ingestion. For DataHub, it means the metadata service (GMS), Kafka, a MySQL or PostgreSQL store, and an Elasticsearch or OpenSearch index. Confirm with your DeployOpen scope document which of these components you will operate yourselves, which your cloud team already runs, and who owns each upgrade path before the project timeline is agreed. The most common slowdowns differ by platform. In OpenMetadata, ingestion is scheduled through Airflow, so an Airflow estate that is still on the Airflow 2 line, which reached end of life on April 22, 2026, can turn a catalog project into an orchestrator migration. Ask whether the Airflow version you run is supported and whether your team has capacity to upgrade it alongside the catalog. In DataHub, the Kafka layer adds operational work: topic configuration, consumer lag, retention and broker upgrades all sit with the platform team, and push-based ingestion from many sources multiplies the number of producers to monitor. Search index sizing is a risk on both sides, because catalogs grow with every table, column and pipeline captured, and a search cluster sized for the pilot may need rework once full source coverage is live. Access and identity are where scope tends to expand late. Decide early how catalog roles map to your identity provider, which teams may edit descriptions and ownership, and whether lineage and classification changes need an approval path. Steward onboarding is the other hidden cost: stewards need time, a documented convention for naming and tagging, and a review rhythm, none of which the software supplies. Write these decisions into the statement of work with named owners, acceptance criteria per source and a list of which features your edition supports, so that the quote reflects the work you actually need rather than a generic catalog deployment.
Questions buyers ask before choosing a metadata catalog
What does it cost to implement OpenMetadata or DataHub?
Both platforms are Apache-2.0 licensed, so the software itself carries no license fee. The cost sits in infrastructure, people and services. Infrastructure depends on the stack each platform needs: OpenMetadata requires Java 21, a MySQL or PostgreSQL database, Elasticsearch 9.x or OpenSearch 3.x, and Airflow for metadata ingestion, while DataHub adds Kafka for streaming metadata changes. Labor covers installation, connector configuration, SSO, backup and upgrades. Ask any provider for a written scope that lists each component, who operates it, and which costs recur after go-live, such as cloud hosting, search capacity and upgrade effort.
How long does a metadata catalog rollout take?
The timeline depends mainly on the number and type of data sources, the depth of ingestion and lineage, and how many teams must adopt the catalog. A platform with fewer moving parts can reach a first working catalog sooner, but connector work usually sets the pace. No duration is fixed here, so ask for a timeline tied to a named list of sources and deliverables. Fixed-scope engagements are agreed in writing before work starts, which makes the schedule easier to check against the agreed deliverables.
What must our team provide during a catalog implementation?
Three inputs decide most outcomes. First, platform engineers need hosting, database, search and network access inside your environment. Second, the integration work needs read credentials for each source system and, where ingestion runs through Airflow or Kafka, a place to schedule and monitor those jobs. Third, data owners must confirm which assets matter, who stewards them, and how ownership and glossary terms should be defined. Without named owners, a catalog fills with metadata nobody trusts. Confirm these responsibilities in writing before work begins.
Can our own team run a metadata catalog without outside help?
A capable platform team can run either platform in-house if it has experience with the components involved. The questions to answer honestly are whether you already operate a relational database, a search cluster, and either Airflow or Kafka, and whether someone owns upgrades. Both projects publish frequent releases, so the upgrade workload is ongoing. Outside help is often used for the first deployment, hardening, documentation and upgrade support, and it can be scoped as a fixed project or a retainer. Decide which of these you will own before choosing.
Which metadata catalog fits our architecture better?
Choose OpenMetadata when your team already runs Airflow for ingestion and wants a server backed by a relational database and a search engine, with a smaller set of moving parts. Choose DataHub when your organization already operates Kafka or expects high-volume metadata change streams, because its metadata service is built around Kafka for streaming changes. If neither stack exists, the cost of adding Kafka or Airflow becomes a deciding factor. Test both against a few real sources before committing.
How do the two catalogs handle security and access control?
Both are self-hosted, so access control depends on how you configure authentication, network placement and database permissions. Confirm in each vendor's documentation which single sign-on and role features are included in the open-source release and which, if any, sit in a commercial edition. Ask for the list of security controls in writing, including how credentials for source systems are stored and rotated. Evidence for compliance assessments can be prepared, but DeployOpen does not issue audit reports or certifications.
What happens to the catalog during upgrades?
Upgrades touch the application, the database schema, the search index and any ingestion components. Both projects ship releases often, and OpenMetadata's bare metal documentation lists version-specific prerequisites. Plan a staging environment, a tested backup and a rollback path before each upgrade. Ask any implementation partner whether upgrades, backups and documentation are included in the fixed scope or sold as an ongoing retainer, and what the handover includes.
Can we switch from one metadata catalog to the other later?
Switching is possible but not free. Each platform stores metadata in its own schema, and connectors, lineage rules, glossary terms and ownership assignments must be recreated or mapped. The cost grows with the number of sources and the amount of manual curation already done. To limit lock-in, keep ingestion configuration in version control, document ownership decisions outside the tool, and ask for an export or migration step in the written scope.
How identity, access and governance requirements affect the choice
Identity integration and role-based governance vary by deployment, so neither platform should be chosen on the strength of a feature name alone. The supplied facts do not establish SSO protocol support, group mapping, audit logging or stewardship workflows for either OpenMetadata or DataHub, so each of these must be confirmed in the current documentation for the exact release you plan to run before architecture decisions are made. Treat the answer as part of the design input, not a later configuration detail.
Start with a short written list of questions and put them to each vendor's current documentation and to a test instance. Ask which SSO protocols each platform supports and whether they can be configured for your identity provider. Ask how external groups from that provider map to platform roles, whether mapping is automatic or manual, and whether it can be managed as code. Ask what audit events are recorded, where they are stored, how long they persist, and whether they can be exported to your SIEM. Ask how stewardship is assigned and whether ownership, approval and review workflows are built in or depend on add-ons.
The answers determine real work for your team. If a platform cannot map groups the way your identity model requires, you will plan custom integration or manual role administration, which recurs with every joiner, mover and leaver event. If audit records cannot leave the platform, your compliance evidence depends on manual exports. Plan a proof of concept that tests these controls end to end with a sample group structure, and record the results before you commit. Where a control is missing, document it as a gap with an owner and a remediation path.
How DeployOpen helps choose and implement a metadata catalog
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For OpenMetadata vs DataHub, we start by mapping your sources, identity setup and governance goals, then deliver a fixed scope agreed in writing before work begins.
How we scope
- Inventory the data sources, warehouses and orchestrators the catalog must ingest from first.
- Confirm the identity provider, role model and access controls the catalog must respect.
- Agree in writing which platform, deployment target and ingestion method fit your environment.
How we build
- Deploy the chosen catalog into your own cloud account, data center or air-gapped network.
- Configure search, database, ingestion pipelines and lineage sources to match the agreed scope.
- Test ingestion runs, access rules and upgrade paths before the catalog is used by teams.
How we hand over
- Document the architecture, configuration, ingestion schedules and backup procedures for your staff.
- Provide runbooks covering upgrades, troubleshooting and removing or adding ingestion connectors.
- Walk your platform and data teams through the delivered system and the evidence it produces.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover.
- Plan version upgrades against the vendor's release notes and your change control process.
- Review ingestion health, access changes and security findings on a schedule you agree.
