What does a data catalog cost when the software is free?
OpenMetadata and DataHub carry no license fee, because both are released under the Apache License 2.0. The money you will spend sits in infrastructure, connector and lineage setup, metadata curation and stewardship time, and ongoing operations. That is the cost to compare against a managed offering such as DataHub Cloud, which its maker describes as managed and SLA-backed with no infrastructure to run, or against a commercial governance suite that bundles licensing, support and hosting into one contract. Neither option is cheaper by default. The comparison only works when you price the same scope on both sides.
The total moves mostly with four variables: the number of sources, the depth of lineage you need (table, column or pipeline), the skills your team already has in Kubernetes, Kafka, search and database operations, and whether the catalog serves internal governance or a public data portal. OpenMetadata's bare metal prerequisites alone call for Java 21, a MySQL or PostgreSQL database and Elasticsearch 9.x or OpenSearch 3.x, and DataHub's architecture adds Kafka and a graph index. Each of those is a running service you patch, back up and size. Ask any partner to split its quote into one-time setup, recurring infrastructure and recurring support, and to state which connectors and lineage paths are included.
DeployOpen does not publish a price list. A quote follows from a written scope that names your sources, lineage requirements, hosting location, stewardship roles and upgrade expectations. Ask for the cost of the first production upgrade, since both platforms change between releases, and confirm how breaking changes and reindexing are handled. For a comparison, request the same scope priced against DataHub Cloud or your governance suite vendor, and ask each side what it will not do for you.
Which cost components apply to in-house, partner and SaaS delivery
This table compares who pays for and who performs each cost component under in-house, partner and managed SaaS delivery, and whether the cost is one-time or recurring. Read each row as a question to answer in your own environment, since OpenMetadata and DataHub are Apache-2.0 and the license itself costs nothing. The main takeaway is that the software fee is rarely the largest line; infrastructure, connector setup and stewardship time usually decide the total.
| Cost component | In-house | Partner or SaaS | One-time or recurring |
|---|---|---|---|
| Infrastructure (database and search) | Your team provisions and pays for compute, storage and the database and Elasticsearch or OpenSearch services; sizing starts from the OpenMetadata bare metal minimums and DataHub's memory guidance | Partner sizes and deploys it in your accounts, so you still pay the cloud bill; SaaS folds this into the subscription | Recurring |
| Connector and lineage setup | Your engineers configure each source connector, pipeline and OpenLineage event feed, and test lineage depth | Partner configures connectors and lineage as fixed-scope work; SaaS vendors may charge for setup services separately | One-time, with recurring changes as sources change |
| Metadata curation and stewardship | Domain owners and data stewards write descriptions, glossary terms and ownership; this is internal time that no license covers | Partner can bootstrap ownership and glossary, but named business stewards still do the approvals and decisions | Recurring |
| Upgrades and operations | Your team tracks releases, runs upgrades (including breaking changes in OpenMetadata 2.0 and the DataHub system-update job) and handles on-call | Partner or retainer covers upgrades, testing and support; SaaS vendors handle platform upgrades under their terms | Recurring |
| Security integration (SSO and access) | Your team configures OIDC or SAML in the self-deployed frontend and maintains role mappings and access policies | Partner sets up SSO and access policy as scoped work; SaaS offers SSO through its own admin interface, which you must confirm | One-time setup, recurring review |
| Licensing | OpenMetadata and DataHub Core are Apache-2.0, so there is no per-user license fee for the open-source core; paid add-ons are a separate question | Managed offerings such as DataHub Cloud and Collate's commercial capabilities are priced by the vendor; request the quote in writing | Recurring for managed or commercial tiers |
| Training and adoption | Internal enablement, documentation and catalog champions | Partner can deliver training as part of scope; SaaS vendors often include onboarding materials | One-time, with recurring onboarding for new teams |
What the in-house build actually requires
A self-hosted build starts with the platform stack, and the two candidates have different shapes. OpenMetadata needs Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later for metadata storage, and Elasticsearch 9.x or OpenSearch 3.x for search. DataHub is a larger set of moving parts: the GMS, the MAE Consumer, the MCE Consumer and the Frontend, plus Kafka for streaming metadata changes, a MySQL, PostgreSQL or MariaDB database, Elasticsearch or OpenSearch, and a graph index on Neo4j or Elasticsearch. Each of these is a component your team must provision, secure, back up and monitor, and each one adds infrastructure cost that recurs every month.
Treat the published figures as starting points, not production sizing. The OpenMetadata bare metal documentation gives a minimum server footprint of 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. DataHub's Kubernetes guide says more than 7 GB of RAM is needed to run DataHub and its dependencies on Minikube, and its README lists 8 GB of RAM for the Docker quickstart. Those figures describe trial environments. Ask the vendor or your implementation partner for sizing based on your source count, metadata volume, profiling schedule and user population, and make that sizing part of the written scope.
The staffing question matters as much as the hardware. Running DataHub on Kubernetes means someone must own the Helm charts from the acryldata/datahub-helm repository, the separate prerequisites chart and the cluster they run on. Upgrades are recurring work: DataHub's Helm chart runs a system-update job that applies schema changes and reindexes search when needed, and OpenMetadata 2.0 introduced breaking changes, including moving embedding credentials into an llmConfiguration block, a new Databricks auth format, rebuilt ingestion images for Python 3.12, and a Great Expectations migration to 1.3 before upgrading. Confirm which of your engineers can perform those upgrades, how long a test cycle takes in your environment, and whether the quote covers upgrades or only the initial install.
Which factors push the data catalog cost up or down
Most of the cost of a self-hosted catalog comes from people and running infrastructure, not the license. The factors below set how many sources, how deep the lineage goes, how much metadata must be curated and how the catalog is deployed, and each one moves the total in a predictable direction.
Number and type of sources
Every source system needs a connector, credentials, a schedule and someone to fix it when a schema changes. OpenMetadata lists more than 130 connectors and DataHub lists more than 150 integrations, but a listed connector still has to be configured, tested and maintained against your versions. Cost rises with each source you add, and it rises faster for custom or legacy systems that have no maintained connector. Ask the partner which connectors they expect to configure, which need custom code, and who owns each one after handover.
Lineage depth
Table-level lineage is a modest configuration task. Column-level lineage and pipeline lineage require parsing SQL, reading orchestrator metadata and, where needed, emitting OpenLineage events from jobs you control. OpenMetadata supports table, column, dashboard, pipeline and metric lineage, and DataHub lists column-level lineage among its features. Each step deeper multiplies the testing effort, so decide which regulated reports or personal data flows need column detail and limit the rest to table level.
Data volume and profiling frequency
Profiling, sampling and freshness checks read the data they describe, so they consume warehouse compute and search capacity. Larger tables and more frequent scans increase both the database and search sizing and the warehouse bill. OpenMetadata 2.0 made Dynamic Sampling the profiler default, which is worth confirming against your table sizes before you set schedules. Ask the partner to show the profiling schedule per domain and the expected load on the source warehouse.
Metadata curation effort per domain
A catalog without owners, descriptions and glossary terms is a search index with stale names. Curation is paid staff time from business domains, stewards and data owners, and it recurs as datasets change. The effort scales with the number of domains, the number of datasets per domain and how many terms must be agreed across teams. Ask who writes the first glossary, how ownership is assigned in bulk and what stewardship time the client must commit each quarter.
SSO and access policy integration
Single sign-on and role mapping are configuration work with a fixed core cost, but the cost grows with identity sources, group structures and access rules. DataHub supports OpenID Connect providers such as Google, Okta and Azure AD, and on self-deployed DataHub Core the operator configures the frontend server. Each additional rule for who sees personal data or restricted domains adds design, testing and review. Confirm which identity provider you use, how groups map to catalog roles and who approves changes.
Deployment model: Kubernetes or bare metal
The deployment model sets the platform engineering effort. OpenMetadata documents production deployments on Kubernetes, including AWS EKS, Azure AKS, Google GKE and on-premises clusters, and on bare metal without Kubernetes. DataHub runs on Kubernetes with Helm charts and a prerequisites chart, and it depends on Kafka and a search index. A cluster you already operate usually lowers the marginal cost, while bare metal needs more manual work for upgrades and backups. Ask for the sizing, the upgrade path and the backup and restore test as separate line items in the quote.
Why stewardship time is often the largest line item
Connectors are the quick part of a catalog project. Ownership, glossary terms, classifications and descriptions are the slow part, and they recur for as long as the estate changes. Both OpenMetadata and DataHub can be pointed at warehouses, BI tools and pipelines with configured connectors, and the metadata they pull in (schemas, tables, dashboards, pipeline runs) arrives quickly. What does not arrive on its own is a named owner for each dataset, a business definition that finance and operations agree on, and a classification that says which columns hold personal or confidential data. Those are decisions made by people, and they are where the calendar goes.
In practice the work is split across three groups. Data owners accept accountability for their domain's datasets and approve definitions. Stewards, often embedded in the business or in a governance team, draft descriptions, map glossary terms, review auto-applied tags and chase missing owners. The platform team handles connectors, permissions, upgrades and the search and database services underneath. Ownership is usually bootstrapped from existing sources such as the warehouse owner field, the BI workspace owner, the source system's data steward list or a service catalog, then confirmed by domain owners. Ask any partner how they plan this bootstrap and who signs off, because a catalog with inherited but unverified owners will mislead users within months.
Quality controls move effort from setup to upkeep rather than removing it. OpenMetadata data quality tests and profiling, and DataHub assertions and monitoring, run on a schedule, so each failing test creates a question for an owner: is the pipeline broken, or has the business meaning changed? Budget for that triage as a recurring role. The practical step is to run a pilot with two or three domains, log the hours each owner and steward spends on ownership, glossary and classification work, and extrapolate from your own measurements. This page does not give a benchmark figure, and any partner quote should show stewardship hours explicitly rather than hiding them inside connector setup.
How to build your own data catalog cost estimate
This sequence turns a vague sense that a self-hosted catalog is cheaper into a line-item estimate you can compare against partner and SaaS quotes. Each step produces a documented input, so the final comparison rests on the same scope and the same period for every option.
Inventory sources and connectors
Your data engineering lead and the owners of each system list every source the catalog must cover, including warehouses, BI tools, pipelines and ML platforms. For each source, record whether a connector exists in OpenMetadata or DataHub, whether it needs a custom build, and who holds the credentials. The step is done when every source has a connector status and an owner, because connector work is one of the largest variable costs.
Decide lineage depth and scope
Governance, risk and data platform leads agree how far lineage must go: table, column, pipeline or metric level, and which domains are in the first phase. OpenMetadata and DataHub both support column-level lineage, but capturing it across every pipeline takes more configuration and review than table lineage. The output is a written scope statement that a partner can price against and that you can use to size effort in later steps.
Size infrastructure from the supplied minimums and a pilot
Your platform engineers start from the documented minimums and then test with a pilot dataset. OpenMetadata's bare metal guide lists Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x, with a minimum server of 2 vCPUs, 4 GB RAM and 20 GB storage, and at least 2 vCPUs, 2 GB RAM and 30 GB storage each for the database and search services. DataHub's Kubernetes guide adds Kafka and a graph index, so its footprint is larger. Minimums are a floor, not a production size: the pilot shows how metadata volume, profiling frequency and search load grow, and the output is a sized infrastructure bill of materials for your cloud or data center.
Estimate stewardship hours per domain
Each data domain's owners and a catalog steward estimate the time to bootstrap ownership, glossary terms, classifications and data quality tests for their datasets. This is usually the largest recurring people cost, and it does not disappear when a managed product is chosen. Record hours per domain, the expected review cadence and who approves changes. The step is complete when each domain has a named steward and an hours estimate that the business has accepted.
Add upgrade and operations effort for the release cadence
Your platform team estimates the operating work for the chosen release line. OpenMetadata published maintenance releases about every one to two weeks after 2.0.0, and its 2.0 notes list breaking changes such as an embedding credentials move and a Python 3.12 image rebuild, so each upgrade needs regression testing. DataHub's Helm chart runs a system-update job on upgrades that can reindex search, which also needs a maintenance window. Document backup, monitoring, on-call coverage and upgrade testing as recurring hours and infrastructure items.
Compare in-house, partner and SaaS over one period
Finance and the catalog sponsor place the in-house estimate, partner quotes and managed SaaS quotes side by side for the same period and the same scope. Split every item into one-time costs, such as connector setup and initial curation, and recurring costs, such as infrastructure, licenses or subscriptions, support and stewardship. Ask each partner and SaaS vendor for written quotes against the identical scope from the earlier steps, and confirm in writing what is included in support, SLAs and upgrades. The output is one comparison table that shows where each option is cheaper and why.
Questions buyers ask about data catalog cost and effort
What does a self-hosted data catalog cost in total?
The software license is not the main cost. OpenMetadata and DataHub are both released under the Apache License 2.0, so the spend falls into four components: infrastructure, connector and lineage setup, metadata curation and stewardship time, and ongoing operations. Infrastructure is recurring and depends on the catalog's own dependencies. OpenMetadata's bare metal documentation lists Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x, with a minimum server of 2 vCPUs, 4 GB RAM and 20 GB storage, and at least 2 vCPUs, 2 GB RAM and 30 GB storage each for the database and search services. Those are minimums for a trial or small estate, not production sizing. Setup and stewardship are one-time or front-loaded, while infrastructure, upgrades and support recur. Ask any partner for a quote that splits these components and states which connectors and lineage paths are in scope.
How long does it take to set up a data catalog?
The timeline depends on scope, and it should be agreed in writing before work starts. The main variables are the number of source systems, whether lineage must reach column level or stop at tables, how many pipelines need to emit lineage, and whether identity integration with SSO is required from day one. A catalog that connects a handful of warehouses and BI tools is a different project from one that must cover the full data estate with glossaries and ownership. For example, an illustrative estate with several warehouses and one orchestrator will take far less configuration than a multi-domain estate with custom metadata models. Ask a partner to show how the scope is broken into connectors, lineage paths, identity setup and stewardship workshops, and to confirm which of those they expect your own teams to complete.
Can our internal team run a data catalog without outside help?
It is possible for teams that already operate Kubernetes or database clusters, but the skills are broader than the catalog itself. DataHub's Kubernetes guide describes Helm charts from the acryldata/datahub-helm repository, a separate prerequisites chart for dependencies, and components that need Kafka, a relational database, Elasticsearch and a graph index. OpenMetadata documents Kubernetes on AWS EKS, Azure AKS, Google GKE and on-premises clusters, as well as bare metal. Your team will need people who can run stateful services, write connector configurations, operate Python ingestion jobs and manage SSO. Confirm your staffing for each area before committing, and ask whether a partner will hand over runbooks and train your operators.
What does a catalog need from business owners and stewards?
A catalog has little value until people with business knowledge define and maintain it. Technical ingestion can populate tables, columns and pipelines automatically, but ownership, business glossary terms, critical data element definitions, domain assignments and classification decisions require named people. Each dataset needs an accountable owner, each glossary term needs an approver, and someone must review automated classifications before they drive access or records decisions. Budget stewardship time as a recurring commitment, not a one-off project phase. Ask any partner how they will bootstrap ownership and glossary content, who signs off on it, and how adoption will be measured after go-live.
Is DataHub Cloud cheaper than running DataHub ourselves?
The answer depends on your staffing, uptime requirements and where your data must reside, and no price comparison can be made from the supplied facts. DataHub is Apache-2.0 licensed, and the company behind it sells DataHub Cloud, which its README describes as managed, SLA-backed and enterprise-ready with no infrastructure to run. Self-hosting removes subscription fees but keeps infrastructure, upgrades, backups and on-call work with your organization. A managed service shifts operations to the vendor but adds a subscription and means metadata is processed in the vendor's environment. Request written pricing from the vendor, the expected infrastructure and staffing for self-hosting, and the data residency terms, then compare the two over the same period.
How do upgrades affect the cost of running a data catalog?
Upgrades are a recurring cost, and they can be larger than expected because they touch the search index, the database and custom connectors. DataHub's Helm chart runs a system-update job on upgrades to apply schema changes and reindex search indices when needed. OpenMetadata 2.0.0 was released on August 24, 2026, with maintenance releases 2.0.1 to 2.0.5 following about every one to two weeks. The 2.0 release made Dynamic Sampling the profiler default, introduced breaking changes including moved embedding credentials and a new Databricks auth format, and required custom ingestion images to be rebuilt for Python 3.12 and Great Expectations to be migrated to 1.3 before upgrading. Plan a staging environment, a test of each connector, and a rollback path, and ask partners how they handle upgrades under a retainer or a fixed-scope engagement.
What licensing questions should we settle before buying a catalog?
Confirm the license of each component, not only the catalog. OpenMetadata and DataHub are both Apache-2.0, and OpenMetadata is maintained by Collate, which also offers commercial enterprise capabilities and premium support. Those commercial features are separate contracts with their own cost. Ask which capabilities you need, such as advanced features or support hours, and whether they are in the open-source distribution. Also check the licenses of the connectors and supporting services you plan to run, since the cost of licensing them can differ from the catalog itself.
What to ask for in a data catalog quote
A comparable written quote for a self-hosted catalog should state the scope of sources and connectors first, by name and by count. OpenMetadata lists more than 130 connectors and DataHub lists more than 150 integrations, but a listed connector is not a configured one. Ask the partner to name each source system, its version, the connector used, whether it runs in push or pull mode, and who supplies credentials. Lineage depth needs the same precision: table, column, dashboard, pipeline and metric lineage are different pieces of work, and OpenLineage event integration is only useful if the orchestrators in your estate can emit those events. The quote should also name the environments covered (development, test, production, and any disaster recovery copy), since each one adds database, search and upgrade effort. Confirm the sizing assumptions in writing, including the database and search services. OpenMetadata's bare metal documentation sets minimums for Java 21, the database and Elasticsearch or OpenSearch, and the quote should show what was assumed beyond those minimums.
Stewardship and adoption deserve their own line items, because they are where most catalog budgets drift. Ask how many hours of bootstrapping ownership, glossary terms and classifications are included, who performs them, and whether the client's stewards or DeployOpen staff do the curation. Specify the SSO configuration as well: on self-deployed DataHub Core the operator configures the OpenID Connect frontend, and the quote should say which identity provider, which groups map to which roles, and whether that is included. For upgrades, ask how breaking changes are handled, such as the OpenMetadata 2.0 changes to embedding credentials and the Python 3.12 rebuild of ingestion images, and whether the DataHub system-update job is tested on a staging copy first. Support terms should state response scope, upgrade frequency and whether they are sold as an ongoing retainer.
Separate one-time costs from recurring ones in every line. One-time items usually include scoping, connector setup, lineage instrumentation, initial curation, SSO and handover. Recurring items include infrastructure, licenses for any commercial add-ons, upgrades, monitoring and steward time. DeployOpen does not publish a price list. Engagements are fixed-scope, so the written scope, deliverables, timelines and handover documents should be agreed before work starts, and any ongoing support, upgrades or continuous testing should be quoted separately as retainers. Ask for the handover package explicitly: architecture diagrams, runbooks, backup and restore procedures, and a record of every configured connector. A quote that cannot describe what the client owns at the end is not comparable with another quote, whatever the total.
How DeployOpen scopes and delivers a fixed-scope catalog implementation
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted catalogs such as OpenMetadata or DataHub inside the client's own cloud accounts, data centers or air-gapped networks. For the cost question, we turn the build, partner or SaaS choice into a written scope that separates infrastructure, connector and lineage work, curation effort and ongoing operations.
How we scope
- Inventory the sources, connectors and pipelines the catalog must cover, with a written list of which are in scope.
- Define the lineage depth, ownership model and glossary effort, so the quote reflects real curation work.
- Agree in writing the hosting, database and search components that the client pays for directly.
How we build
- Deploy the catalog, its database and search services in the client's infrastructure, with sizing set from the agreed source count.
- Configure connectors, ingestion schedules, lineage capture and SSO, then test each against the written scope.
- Run security testing on the deployed catalog and its APIs before handover, with findings tracked to closure.
How we hand over
- Deliver architecture, runbooks, connector configuration and a cost-of-operation sheet the client can keep.
- Train the named data owners and stewards on curation tasks so the metadata work stays with the client.
- Document upgrade steps for each release, including breaking changes, so future upgrades are planned rather than improvised.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, priced separately from the build.
- Review connector health, search capacity and storage growth with the client on an agreed schedule.
- Confirm with the client which recurring costs stay internal, such as steward time, and which are contracted.
