What an OpenMetadata implementation involves
An OpenMetadata implementation means running the catalog and governance layer on infrastructure you control: a server, a metadata database, a search index, an ingestion scheduler and identity integration, all deployed inside your cloud accounts, data center or air-gapped network. OpenMetadata is released under the Apache License 2.0 and maintained by Collate, which also offers commercial enterprise capabilities and premium support. Choosing the open-source route is a licensing and operating decision, so confirm early which parts of your scope depend on features that only exist in the commercial edition.
Teams usually scope this work after one of a few events. A new data platform goes live with no agreed place to record owners and definitions. An audit or access review asks who owns a sensitive table and where it came from, and nobody can answer quickly. A data incident exposes lost lineage between a dashboard and the pipeline behind it. Or the catalog is a spreadsheet that has drifted from reality. Each trigger points to different first priorities, such as ownership and domains for access questions, or pipeline and column lineage for incident response.
The first decision is whether your own platform team can carry the build and the ongoing operation, or whether a partner should plan and implement it under a written scope. The in-house route suits teams with spare Kubernetes or bare metal capacity, database operations skills and a named data steward group. A partner is more often useful for the initial design of domains, glossary and ownership, connector onboarding and hardening, where the work is decision-heavy and needs a fixed deliverable. Ask any partner to show how the scope, deliverables and handover will be recorded before work starts.
What the work includes
A written OpenMetadata scope usually breaks into the work packages below. Each one ends in a named deliverable the client keeps, so the quote can be checked line by line against what you receive.
Deployment target and environments
The scope fixes where OpenMetadata runs (Kubernetes on EKS, AKS, GKE or an on-premises cluster, or bare metal) and how many environments exist. Bare metal needs Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x. Deliverable: installed, documented development, test and production environments with sizing notes.
Connector onboarding
OpenMetadata lists more than 130 connectors, but your scope should name only the sources you need for the first release, such as warehouses, BI tools and pipelines. Each connector carries its own credential setup, network path and ingestion schedule. Deliverable: configured and tested ingestion for each agreed source, plus a connector register listing owners and schedules.
Domains and glossary
Domains group assets by business area, and the glossary fixes shared business terms before they are attached to tables. Agreeing both is mostly workshop time with business owners, and it drives how much rework follows later. Deliverable: a configured domain structure and an approved glossary with term owners and review rules.
Ownership and stewardship model
This package defines who owns each domain, who stewards each dataset and who approves changes to glossary terms and classifications. Ask whether the model maps to existing teams or needs new roles, since that decision determines the effort on the client side. Deliverable: a written ownership and stewardship model with assigned owners and an escalation path.
Classifications
Classifications tag sensitive and regulated data such as personal or financial fields, and they should follow your existing data policy rather than a generic template. Confirm who reviews tags and how tags propagate to downstream assets. Deliverable: a classification scheme with tag definitions, assignment rules and a named approver.
Data quality and profiling setup
Tests, profiler sampling and freshness checks run queries against your warehouses, so their cost and load depend on sampling choices and schedules. Failed tests must route to a named data owner. Deliverable: configured tests and profiler jobs for agreed tables, documented thresholds and an alert routing map.
Lineage sources
Table, column, dashboard and pipeline lineage can come from connectors, query logs or OpenLineage events, and each source covers different gaps. Confirm which sources your pipelines emit and where extraction will miss lineage. Deliverable: configured lineage sources and a list of known gaps with the owners responsible for closing them.
Handover
Handover transfers configuration, runbooks and access to your team so they can operate the catalog after the engagement ends. Ask for the exact list of artifacts and a walkthrough recording or session. Deliverable: runbooks, configuration documentation, an admin access register and a completed handover session with your operators.
What drives cost and duration
Each row names one factor that moves OpenMetadata rollout effort, why it does so, and how to keep it contained before the quote is written.
| Driver | Why it moves effort | How to keep it contained |
|---|---|---|
| Number and type of sources | Each connector needs a service account, network path, ingestion configuration, filters and validation against real metadata. OpenMetadata lists more than 130 connectors, but each one you enable still has its own setup and test cycle. | Onboard the warehouses and BI tools that answer the first governance questions, and defer the rest to later phases with a written list. |
| Domains and glossary terms | Domains need owners, boundaries and assignment rules for each asset. Glossary terms need definitions, approvers and links to assets, and the work grows with every business area that joins. | Start with a small set of domains and a limited glossary agreed by business owners, then add terms through a defined intake process. |
| Ownership model complexity | Simple models map one owner per asset. Layered models with stewards, domain owners, team inheritance and approval rules need design workshops and rules that must be tested against real data. | Choose the simplest ownership model that meets audit and stewardship needs, and document exceptions as they come up. |
| Data quality test volume and warehouse query cost | Each test and profiler run issues queries against your warehouse, and test suites multiply as coverage expands. Failure routing also needs owners and alert paths set up for each suite. | Limit profiling to priority tables, use sampling, schedule runs outside peak warehouse hours and confirm query cost with your warehouse team before expanding coverage. |
| Deployment target | Kubernetes on AWS EKS, Azure AKS, Google GKE or on-premises clusters adds cluster-level work such as ingress, storage classes and secrets. Bare metal needs Java 21, a supported MySQL or PostgreSQL database and Elasticsearch 9.x or OpenSearch 3.x configured by hand. Docker suits trials but is not a production pattern for this scope. | Reuse an existing, supported cluster platform where your organization already runs one, and confirm the production pattern with your platform team before design starts. |
| Environments | Each environment (development, test, production) repeats deployment, connector configuration, SSO setup and data access approvals. Drift between them is a common source of rework during cutover. | Keep environments as code, promote configuration through a single pipeline and limit production to approved connectors and data. |
| Identity integration scope | OpenMetadata documents SSO with Auth0, Azure, Google, Okta, Amazon Cognito, OneLogin, Keycloak and custom OIDC providers. The provider choice, group mapping to teams and roles, and the switch off basic authentication each add design and testing. SSO and basic authentication cannot be used together. | Agree the identity provider, group model and cutover date early, and plan the basic authentication shutdown as a single, tested step. |
| Compliance evidence needs | Assessors may ask for access reviews, change records, data classification evidence and proof that ownership and quality controls operate. Preparing that evidence means configuring logging, retention and reporting for OpenMetadata itself. DeployOpen prepares evidence for independent assessors but does not issue audit reports or certifications. | Ask the assessor or compliance lead to list the specific evidence they need before design, then build only those reports and controls into the plan. |
| 2.0 upgrade if starting on 1.x | OpenMetadata 2.0.0 was released on August 24, 2026. Its breaking changes include moving embedding credentials into an llmConfiguration block, a new Databricks auth format, rebuilding custom ingestion images for Python 3.12 and migrating Great Expectations to 1.3 before upgrading. Each one touches configuration, images or tests. | If you start on 1.x, decide the target version first, inventory custom ingestion images and affected connectors, and fold the migration into the initial plan rather than a later project. |
Project phases and outputs
The sequence moves from agreed scope to a handed-over OpenMetadata platform that your data owners can run, with each phase closing on a named output.
Run discovery and scoping
DeployOpen reviews your deployment target, data sources, domains, expected connectors, identity provider and data owners with your platform and data teams. The phase closes with a written scope covering deployment model, connector list, domain and glossary model, data quality priorities and the timeline, which is agreed before build work starts.
Build the platform foundation
The team installs OpenMetadata on the chosen target, whether Kubernetes or bare metal, with its database and search services sized to the agreed scope and configured for backups. The phase closes with a running, non-production instance, its component versions recorded, and a tested restore of the database.
Onboard connectors
Each source in the agreed connector list is configured with a dedicated service account, scoped read access and a scheduled ingestion pipeline. The phase closes with metadata ingested for every in-scope source, a record of which connectors ran cleanly, and a list of any gaps that need follow-up.
Build the governance model
Domains, glossary terms, classifications, ownership assignments and team roles are configured to match the agreed model, and connected to your identity provider where that is in scope. The phase closes with a populated glossary, named owners for priority assets and a sign-off from the data owners who will maintain them.
Configure data quality and profiling
Profiler sampling, data quality tests and freshness checks are set up for the priority tables, with thresholds agreed with data owners and routing rules that send failures to the right people. The phase closes with a test suite running on schedule, a documented sampling approach and an agreed view of expected warehouse query load.
Validate and hand over
DeployOpen and your team check ingestion results, lineage, ownership, glossary coverage and test outcomes against the written scope, then move the platform to production. The phase closes with a validation record, operations runbooks, administrator training and a handover of credentials, backups and monitoring to your team or to a support retainer.
What usually goes wrong
These failure patterns appear in OpenMetadata rollouts that skip early decisions. Each card names the check to complete before the work is scheduled.
Undersized database and search services
OpenMetadata's documented minimums are 2 vCPUs, 4 GB RAM and 20 GB storage for the server, with the database and search services each needing at least 2 vCPUs, 2 GB RAM and 30 GB storage. Those figures are floors. Estimate storage from the tables, columns, profiler runs and lineage edges you plan to load, and confirm search index sizing with the vendor before ordering infrastructure.
Deployment target chosen before the team can run it
Teams often select Kubernetes or bare metal before anyone has operated either. Bare metal requires Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x, all patched and backed up by your team. Kubernetes adds cluster operations on EKS, AKS, GKE or on-premises clusters. Name the people who will patch, back up and upgrade the chosen target before committing to it.
Connector credentials and network access unresolved
Each connector needs a service identity with read access to its source and a network path from the ingestion workers. Teams often find at the first scheduled run that a warehouse firewall blocks the workers or that a shared password has no owner. Before onboarding, list every source with its credential holder, rotation process and egress route.
Ownership without named stewards
Assets, glossary terms and domains need a named owner. When a project team assigns stewards once and nobody confirms them, lineage gaps and failed quality tests route to no one. Agree on steward roles per domain and a rule for who approves glossary changes before the first connector goes live. Include the recurring stewardship time in the cost estimate.
Embedding credentials and Databricks auth changed in 2.0
OpenMetadata 2.0 moved embedding credentials into an llmConfiguration block and introduced a new Databricks auth format. Settings written for 1.x can stop working after the upgrade. Inventory every Databricks connection and embedding setting in your current install, rewrite them in a test environment and confirm they load before planning cutover.
Ingestion images and Great Expectations 1.3 found late
Custom ingestion images must be rebuilt for Python 3.12 with Apache Airflow 3.3.0, and Great Expectations must migrate to 1.3 before the upgrade. Teams that discover these gaps during cutover lose a release window. List every custom connector and Great Expectations check, rebuild the images in staging and run each connector once before go-live.
What stays in-house and what a partner covers
This table compares the OpenMetadata work your team usually keeps with the technical work a partner often takes on, along with the skills each part needs, so you can judge where to draw the line.
| Work area | Usually stays in-house | Often outsourced and skills needed |
|---|---|---|
| Business definitions and glossary content | Writing term definitions, approving synonyms and deciding which terms are authoritative. Needs domain experts and data governance practice. | Not usually outsourced. A partner can import existing glossaries and draft a template, but meaning must come from your domain owners. |
| Domain ownership and steward decisions | Assigning domain owners, deciding who approves changes and resolving disputes about data meaning. Needs governance leadership and business knowledge. | Partner can configure the domain, team and role structure in OpenMetadata as decided. Skills needed: OpenMetadata administration and access model design. |
| Deployment target | Choosing the hosting model, approving the cloud or data center target and owning the long-term operating budget. | Installing on Kubernetes (EKS, AKS, GKE or on-premises) or bare metal. Skills: Kubernetes or bare metal administration, Java 21, and MySQL or PostgreSQL plus Elasticsearch or OpenSearch operations. |
| Connector configuration | Listing which sources matter, naming owners for each source and approving credential scope. | Creating and testing connectors for warehouses, BI tools and pipelines. Skills: source system knowledge, database permissions and OpenMetadata connector configuration. |
| Ingestion pipeline setup | Setting refresh expectations and deciding which assets are in scope for ingestion. | Building scheduled ingestion, handling failed runs and tuning run frequency. Skills: data engineering, Airflow or scheduler operations and Python packaging. |
| API automation | Defining which metadata updates should be automated and reviewing what gets written back. | Writing scripts or pipelines against REST APIs, Python SDK or Java libraries. Skills: software engineering and API integration experience. |
| Handover and operations | Taking over runbooks, owning ongoing stewardship and approving upgrades for production. | Documenting the install, training administrators and delivering runbooks for backups and upgrades. Skills: technical writing, backup operations and change management. |
How the scope changes by starting point
A fresh install has the fewest moving parts, so the scope centers on choosing the deployment target and deciding what the first catalog contains. Plan the first release around a small set of domains and the sources that feed them, then expand.
- Deployment target: choose Kubernetes or bare metal, which sets which database and search services you run and who operates them.
- Authentication: decide the identity provider before go-live, because OpenMetadata does not support SSO and basic authentication at the same time.
- Ownership model: name owners and stewards for the first domains before connectors start running.
- Connector list: confirm which of the more than 130 connectors your sources need and check network reachability from the ingestion host.
- Sizing: ask for database and search sizing based on your expected asset count, starting from the documented minimums.
Moving from a spreadsheet or another catalog adds a data mapping workstream on top of the install. The migration topic covers the mechanics, so this tab only shows how the scope changes.
- Source inventory: list every spreadsheet, catalog export and owner list before deciding what moves.
- Mapping decisions: decide how existing terms, owners and classifications map to glossary terms, domains and tags.
- Parallel running: agree whether the old catalog stays read-only for a period after cutover.
- Cutover sign-off: decide who reviews reconciled metadata and approves the switch for users.
- Effort driver: the number of sources and how complete their ownership data is are among the main factors in the effort.
An upgrade from 1.x is a project in its own right because OpenMetadata 2.0 includes breaking changes. Scope it as a separate upgrade with its own test cycle and rollback plan, using the release notes for 2.0.0 as the reference.
- Embedding credentials: move embedding credentials into the llmConfiguration block.
- Databricks authentication: update connection settings to the new Databricks auth format.
- Custom ingestion images: rebuild them for Python 3.12 and retest every custom connector.
- Great Expectations: migrate to 1.3 before upgrading, since this is a prerequisite.
- Feature defaults: review the new Dynamic Sampling profiler default and MCP being enabled by default, then decide whether to keep them.
Kubernetes and bare metal produce different scopes. Kubernetes moves much of the work into cluster operations, while bare metal makes your team build and run the database and search tiers directly.
- Kubernetes: OpenMetadata documents production use on EKS, AKS, GKE and on-premises clusters. Confirm who owns the cluster, storage classes and ingress.
- Bare metal prerequisites: Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x.
- Minimum sizing: the server minimum is 2 vCPUs, 4 GB RAM and 20 GB storage, with the database and search services each needing at least 2 vCPUs, 2 GB RAM and 30 GB storage. Confirm production sizing separately.
- Patching: on bare metal, operating system, Java and service patching fall to your team.
- Docker: the documented Docker setup is for local trials, not a production target.
An air-gapped network changes how software and updates reach the environment more than how the platform is designed. Confirm the specifics with OpenMetadata and your security team, because the details depend on your enclave's rules.
- Artifact intake: define how server packages, container images, connector libraries and upgrade files are transferred, scanned and approved.
- Connector reachability: confirm that every source system sits inside the enclave or has an approved path, and expect that cloud-only sources may need a different approach.
- Identity provider: the SSO provider must be reachable from inside the enclave.
- Update cadence: agree how often releases and patches move across the boundary, and who approves each transfer.
- Install dependencies: confirm which components need outbound access during installation and upgrades, and plan for offline equivalents.
What the client needs to provide
Most delays in an OpenMetadata rollout start with inputs the client was expected to supply and did not. Before scoping, the client should provide access to the cloud accounts, Kubernetes clusters or bare metal hosts where OpenMetadata will run, along with a named target environment and the network paths it needs to reach the data sources. The platform owner signs off on the environment. The security team signs off on network access and any firewall changes.
A source inventory with named owners is the single most important input for connector scoping. For each warehouse, BI tool, pipeline or ML platform to be onboarded, the client should list the system, its version, the team that owns it and the service account DeployOpen will use to connect. The data owner for each source signs off on its inclusion. The credentials policy should be agreed in the same step: where connector secrets are stored, who can rotate them, and whether read-only accounts are acceptable for profiling and lineage extraction.
Governance inputs come from people, not systems. The client must name a governance lead who can make decisions on glossary terms, classifications and domain boundaries, and a domain owner for each business area that will own assets. Sample data for profiling should be provided with its sensitivity classification, so the team can agree which tables may be sampled and where. The governance lead signs off on the domain model and glossary scope.
Two decisions gate the build. The first is the identity provider, such as Okta, Azure, Google, Keycloak or a custom OIDC provider, because OpenMetadata does not support combining SSO with basic authentication, so the choice affects user provisioning from day one. The second is the edition: the Apache License 2.0 release maintained by Collate, or Collate's commercial offering with its enterprise capabilities and premium support. The CISO or IT director signs off on the identity provider, and the budget holder signs off on the edition.
Frequently asked questions
How is the cost of an OpenMetadata implementation built up?
The cost follows from the written scope, which lists the deployment target, the connectors to onboard, the domains, glossary and ownership model, and the data quality checks to configure. Each item carries its own design, build, testing and handover effort, and the quote adds those together. Ask the partner to show effort per line item so you can see which items you could remove or defer. Infrastructure you pay your cloud or data center provider for is separate from the implementation fee, so confirm who owns that spend.
What is one-time work and what recurs after go-live?
One-time: scoping, deployment, connector setup, glossary and ownership design, data quality configuration, SSO setup and handover. Recurring: upgrades, connector maintenance, backup checks, ingestion schedule changes and steward work on new data. OpenMetadata is released under the Apache License 2.0, so the software itself carries no license fee for self-hosting, but ask each partner which recurring support, upgrade and testing items are included in their quote and which need a separate retainer.
How long does an OpenMetadata rollout take, and what sets the timeline?
Duration depends on how many sources you connect, how much metadata needs cleaning or mapping to owners, and how many approvals the operating model requires. A single deployment with a few connectors moves faster than a multi-domain rollout with custom ingestion and lineage gaps to fill. Ask for milestones tied to written acceptance criteria rather than a single end date, and confirm with the partner how their timeline assumes your team's availability for reviews and access requests.
Can an internal team implement OpenMetadata without outside help?
Yes, many teams do, provided they have engineers who can run Java 21 services, a supported relational database, and Elasticsearch 9.x or OpenSearch 3.x. Bare metal prerequisites are Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x, with minimum server sizing of 2 vCPUs, 4 GB RAM and 20 GB storage. The harder work is usually ownership design and stewardship, which depends on business decisions your team must make either way.
What does our organization need to supply before the work starts?
Expect to provide network access to sources, service accounts with least-privilege read access, a named owner for each domain, the glossary terms your business uses, identity provider details for SSO, and hosting capacity in your cloud or data center. Delays usually come from slow access approvals and unclear ownership decisions. Confirm in writing which of these items the quote assumes you provide and which the partner handles.
How should we compare partner quotes for OpenMetadata?
Compare quotes against the same written scope, not against headline totals. Check that each quote states the deployment target, connector list, domains, glossary and ownership model, data quality work, SSO scope, testing and handover, and what is excluded. Ask which items are fixed and which are estimated, what changes trigger a new quote, and what recurring support or upgrade work is priced separately. Ask for the OpenMetadata version each quote targets, since 2.0.0 introduced breaking changes that affect upgrade effort.
How DeployOpen scopes and delivers this work
DeployOpen plans, implements, customizes, hardens, documents and supports OpenMetadata inside your own cloud accounts, data centers or air-gapped networks. Each rollout starts from a written, fixed scope that sets deployment target, connectors, domains, glossary and ownership model before any build work begins.
How we scope
- Confirm the deployment target, whether Kubernetes on EKS, AKS, GKE or on-premises, or bare metal, before sizing begins.
- List each connector to onboard across warehouses, BI tools, pipelines and ML platforms, with its source owner and access path.
- Agree domains, glossary terms, classifications and the ownership model in writing, including who approves changes and who maintains each domain.
How we build
- Stand up the Java 21 server, database and Elasticsearch or OpenSearch tiers sized to the prerequisites the vendor documents.
- Configure SSO and connector credentials, then run ingestion for each source against a test scope before wider rollout.
- Set up lineage sources such as query logs and OpenLineage events, plus data quality tests and profiler settings agreed in the scope.
How we hand over
- Deliver runbooks for deployment, ingestion schedules, backup and restore, and the connector inventory for your team.
- Document the scoped domains, glossary, ownership model and access policies as they were built, not as they were first planned.
- Run a handover session with your platform and data governance owners and record open items against the written scope.
How we support
- Engagements are fixed-scope, and ongoing support, upgrades and continuous testing are available as a retainer.
- Plan upgrades around OpenMetadata release notes, including breaking changes and any Great Expectations or ingestion image rebuilds they require.
- Ask for the retainer terms, response expectations and upgrade coverage in writing before the scope is signed.
