What an OpenMetadata implementation involves
OpenMetadata is an Apache 2.0 licensed metadata platform. It combines a data catalog, lineage, data profiling and quality tests, a business glossary, classification and governance workflows on one metadata model defined by JSON schemas. Collate offers a managed and commercial edition built on the same project.
Connecting a warehouse and seeing tables appear takes little effort. A catalog that people trust takes more: a domain structure that matches how the business divides data, owners for each asset, glossary terms with agreed definitions, classification rules for sensitive data, and quality tests on the tables that matter.
DeployOpen works with your data and governance teams on that model, builds the connectors your stack needs and deploys OpenMetadata in your infrastructure.
Architecture and requirements
Minimum versions from the OpenMetadata 2.0.x production requirements, checked in October 2026. Confirm against the documentation for the release you deploy.
| Component | Role | Notes |
|---|---|---|
| OpenMetadata server | Java service that hosts the REST APIs, UI, governance workflows and search indexing. | Java 21. Run more than one replica behind a load balancer for availability. |
| Metadata database | Source of truth for all entities, relationships and history. | MySQL 8.0.42 or later, or PostgreSQL 15 or later. Managed services such as RDS or Cloud SQL are supported. |
| Search engine | Powers discovery, search and parts of the UI. | Elasticsearch 9.3.0 or later, or OpenSearch 3.4.0 or later. Indexes can be rebuilt from the database. |
| Ingestion orchestration | Schedules and runs connector, profiler, lineage and quality workflows. | Apache Airflow, or the Kubernetes-native orchestrator added in 1.12 using Jobs and CronJobs or an operator. |
| Ingestion framework | Python package and container image that run connectors. | Images moved to Python 3.12 in 1.13.4. Workflows can also run from your own scheduler with the metadata CLI. |
Design the metadata model
These decisions shape how people find, trust and govern data in the catalog.
Domains and data products
Domains group assets, glossaries and teams by business area, and data products package assets that a domain offers to others. Define them with the business, then map connectors and assets into them.
Teams and ownership
Teams nest from organization through business units, divisions and departments to groups, and only groups own data assets. Sync teams and users from your identity source and assign owners at ingestion time where possible.
Glossary and classification
Glossary terms hold business definitions, with reviewers who approve new and changed terms. Classifications and tags mark sensitivity such as PII. An auto-classification workflow can tag likely personal data, and stewards should review its results.
Custom properties
Custom properties extend entity types with fields your organization needs, such as retention class or source system. Keep the list short and governed.
Lineage
Lineage comes from query logs, view definitions, dbt and pipeline connectors, and can be edited by hand. Decide which systems must show end-to-end lineage and test that the parsers handle your SQL.
Data quality
Tests run on tables and columns, from built-in checks to custom SQL, and failures can open incidents for owners to resolve. Release 2.0 changed the profiler default to dynamic sampling.
Connectors, custom development and upgrade cost
OpenMetadata ships connectors for databases, warehouses, BI tools, pipelines, messaging, ML and storage systems. Each needs a service account with read access to metadata and, for profiling and quality, to data. Agree with system owners on scope, schedule and query load.
For systems without a connector, write a Python class on the ingestion framework that yields entity requests, package it, and build a custom ingestion image from the base image of the matching OpenMetadata version. Database, pipeline, dashboard and messaging services all accept custom connectors through the UI.
The REST API and Python SDK cover the entity model, so ownership, tags and glossary terms can be set from CI, provisioning scripts or a data contract process. Alerts and webhooks send changes to chat tools, email or any webhook endpoint.
Custom connectors and ingestion images must be rebuilt for each release, and connector schemas can change; release 2.0 restructured Databricks pipeline authentication. Keep custom code small, pinned to the server version and covered by a test run against a sample system.
Discovery, migration and rollout
Discovery starts with the questions the catalog should answer: who owns this table, can I use this column, where does this report's number come from, and what broke when a pipeline failed. The answers decide which systems, owners and lineage come first.
Teams often arrive from spreadsheets of data definitions, a wiki glossary, another catalog such as Amundsen or Apache Atlas, or metadata scattered across dbt projects. Glossaries can be loaded through CSV import or the API, and ownership and descriptions can be scripted from existing sources.
Roll out one domain first with its owners, glossary and quality tests in place, then extend domain by domain. Train owners on curation and tasks, analysts on search and lineage, and the platform team on ingestion and upgrades.
Security, SSO and access control
Which sign-in options are supported?
The 2.0.x documentation covers SSO with Okta, Microsoft Azure, Google, Auth0, Amazon Cognito, OneLogin, Keycloak and custom OpenID Connect providers, plus LDAP. Only one authentication mechanism can be active at a time, so plan the cutover from basic authentication and remove the default admin account afterwards.
How does authorization work?
Roles bundle policies, and policies are allow or deny rules on resources and operations, optionally with conditions such as ownership or tags. Policies can be attached to teams so that members inherit them. Define a small set of roles before onboarding users.
How are connector credentials protected?
By default, service connection secrets are stored in the OpenMetadata database. The documentation describes integration with external secrets managers, including AWS Secrets Manager and Parameter Store, after which only permitted users can view or edit connection details. Use read-only service accounts for every source.
What else needs hardening?
Replace the default JWT signing keys, which are meant only for quickstart use, and manage bot tokens such as the ingestion bot as secrets. Enable TLS to the database and search engine, restrict network access to the server and search cluster, and review the MCP server, which 2.0 enables by default, against your policy for AI tool access.
Hosting, backups and upgrades
OpenMetadata documents production deployments on Kubernetes with Helm charts and on bare metal. For availability, run several server replicas, a highly available MySQL or PostgreSQL service and a search cluster with replicas. The database is the source of truth; search indexes can be rebuilt from it with the reindex job.
Back up the database with mysqldump, pg_dump or managed snapshots on a schedule and before every upgrade, along with Helm values, configuration and custom ingestion images. The project notes that a backup taken on one version should not be restored into a higher version, so rehearse restores on the same version.
Upgrades follow a fixed order: back up, upgrade the server and run its database migrations, reindex search, update the ingestion client and any external Airflow packages to the same version, then redeploy ingestion pipelines. Read breaking changes for each release; the 1.13 to 2.0 notes include configuration moves for semantic search and a new profiler default.
OpenMetadata operating ownership
A catalog stays useful only when the platform, the metadata and the governance process each have an owner.
Data platform team
- Runs the server, database, search cluster and orchestrator.
- Maintains ingestion pipelines and custom connectors.
- Applies upgrades and reindexes after each one.
Data owners
- Own assets in their domain and keep descriptions current.
- Respond to tasks and quality incidents.
- Decide who may use sensitive data.
Governance and stewards
- Maintain the glossary and review new terms.
- Define classification rules and sensitive data tags.
- Report on ownership and documentation coverage.
Security
- Review roles, policies and bot tokens.
- Control connector credentials and secrets management.
- Track advisories and upgrade timing.
OpenMetadata implementation questions
How does OpenMetadata compare with DataHub?
Both are Apache 2.0 licensed metadata platforms with catalog, lineage and governance features. DataHub's reference architecture uses Kafka for metadata change events alongside a database and search index. OpenMetadata runs with a database, a search engine and an ingestion orchestrator, with no message bus. Compare them on your connector list, governance workflows and operating capacity.
Do we need Airflow?
Not necessarily. OpenMetadata can use Airflow, the Kubernetes-native orchestrator added in 1.12, or your existing scheduler running the ingestion CLI.
Should we self-host or use the managed edition?
Self-hosting keeps metadata, credentials and query access inside your environment and gives full control over upgrades. Collate's managed edition reduces operating work. We help you compare them against your data residency rules and team capacity.
Scope and handover
Effort depends on the number of source systems, how many need custom connectors, the state of existing definitions and ownership data, lineage expectations, quality test coverage, identity integration and availability targets. Curating the model and onboarding owners usually take longer than deploying the platform.
DeployOpen runs discovery with data and governance teams, designs domains, teams, glossary and classification, configures and builds connectors, deploys and hardens OpenMetadata in your environment, integrates SSO and secrets management, and sets up backups and a restore test. Handover includes the metadata model documentation, connector inventory with service accounts, custom connector repository, role and policy definitions, upgrade runbook and restore test record.
