Where a self-hosted catalog costs less than Microsoft Purview, and where it costs more
If you are weighing a Purview renewal or a billing change, the license line disappears, but the rest of the bill moves onto your books. Infrastructure, implementation, migration and the staff who operate the catalog all become costs you pay directly, either as internal salaries or as fees to a partner. Whether the total goes down depends on your governed asset count, your DGPU consumption for data quality and health controls, and the skills you already have in platform engineering and data governance. No fixed price comparison is supplied for this page, so you will need to build your own model from your current invoices and your own environment.
Both candidates are a useful starting point for that model. OpenMetadata is released under Apache-2.0 and maintained by Collate, which offers commercial enterprise capabilities and premium support. DataHub is also Apache-2.0 licensed, and its company sells DataHub Cloud as a managed, SLA-backed option. In both cases the open-source edition is free to download, but the commercial add-ons are separate line items you should price if you need them. Both projects document a Kubernetes deployment path with Helm, so your existing cluster operating costs are a major cost driver to size before anything else.
The costs that recur most often sit in the components rather than the license. For a self-hosted deployment, ask your team to list the database, search cluster, ingestion compute, Kafka where it applies, backups, monitoring, upgrades and on-call time, then assign an owner and a monthly run cost to each. Check the OpenMetadata bare metal deployment docs for the stated minimum sizing of its database and search services, and confirm current production sizing with the vendor before you rely on it. For DataHub, confirm the resource needs of GMS, the consumers, the frontend and their dependencies with the Kubernetes guide and your own load tests.
Which cost components move when you leave Purview
This table compares each cost component of Purview Unified Catalog with the equivalent in a self-hosted OpenMetadata or DataHub deployment, and marks whether each one is one-time or recurring. Read it as a checklist for building your own total cost, since the commercial side is billed by usage meters you should confirm with Microsoft. The main takeaway is that self-hosting removes the vendor subscription but moves infrastructure, implementation and operating work onto your own budget and staff.
| Cost component | Commercial side (Purview) | Self-hosted side (OpenMetadata or DataHub) | One-time or recurring |
|---|---|---|---|
| Subscription | Billed per governed asset and per data quality processing unit (DGPU); confirm current meters on Microsoft's pricing page | No license fee for the open-source editions; Collate and DataHub Cloud are optional paid products | Purview: recurring. Self-hosted: none for the core software |
| Infrastructure | Included in the service; no servers for you to size | Kubernetes or bare metal hosts, MySQL or PostgreSQL, Elasticsearch or OpenSearch, and Java 21 for OpenMetadata; DataHub also needs Kafka and a graph index | Recurring (compute, storage, backups, networking) |
| Data quality compute | Consumed as DGPU during quality runs and health controls | Profiling and tests run on your ingestion and compute, sized by source volume and schedule | Recurring; scales with run frequency |
| Implementation | Setup of Data Map, collections and Unified Catalog governance domains | Deployment, connector configuration, SSO, backup design and hardening, often by your team or a fixed-scope partner | One-time, with later change work |
| Migration | Export is not one-click; rescanning and rebuilding glossary, owners and rules | Ingesting sources again, mapping domains, carrying over glossary and ownership data | One-time |
| Upgrades and support | Included in the subscription; Microsoft operates the service | Your team plans and tests upgrades, including breaking changes and schema migrations; support is optional paid | Recurring |
| Internal skills | Governance and catalog administrators in the Azure portal | Staff who run Kubernetes or database services, search, Kafka where applicable, and catalog administration | Recurring; hiring or training is a one-time step |
What moves the Purview versus self-hosted comparison
Six drivers decide whether a self-hosted catalog costs less than Microsoft Purview Unified Catalog for your estate. Each one moves the bill in a different direction, and several shift cost from Microsoft to your own staff and infrastructure. Model them against your own asset counts, source list and uptime requirements before comparing totals.
Governed asset count
Purview bills per governed asset, so the number of assets you bring under governance is the main recurring driver. Self-hosted OpenMetadata or DataHub has no per-asset licence fee, so growth shows up instead as database rows, search index size and ingestion run time on your servers. Ask Microsoft how it defines a governed asset and whether that matches the tables and dashboards you plan to ingest.
DGPU for data quality and health
Data quality and health controls consume data quality processing units (DGPU) on the Purview side, so the more rules you schedule and the more often they run, the higher the bill. In a self-hosted catalog the equivalent work runs on your ingestion and profiling compute, which you size and pay for directly. Count your planned checks and their frequency before you compare, because profiling cost scales with table size and schedule.
Connectors outside Azure
Purview is strongest where your estate is already Azure-centric. If you need sources on other clouds, on-premises databases or SaaS tools, each one adds connector setup and maintenance work. OpenMetadata lists more than 130 connectors and DataHub lists more than 150 integrations, but you should confirm each source you depend on is supported and whether your team or a partner maintains the ingestion recipe.
Availability requirements
DataHub Cloud lists a 99.5% uptime SLA as a managed feature. A self-hosted catalog carries no vendor SLA, so the uptime target becomes your responsibility, including high availability for the database, search and Kafka layers in DataHub. Decide whether the catalog is a convenience tool or a dependency for access requests and compliance evidence, because that choice sets how much redundancy and on-call coverage you must budget for.
Data volume and search sizing
Metadata volume grows with table count, column count, profiling history and lineage edges, and that growth drives database storage and search index size. OpenMetadata documents minimum sizing for its database and search services, but production sizing depends on your estate. Ask a vendor or partner for a sizing estimate based on your actual metadata volume, and plan storage growth over the retention period you choose.
Kubernetes and data engineering skills
Staff time is the cost most often missing from comparisons. DataHub's Kubernetes guide covers GMS, the consumers, Kafka, a relational database, Elasticsearch and a graph index, and upgrades run a system-update job that you must monitor. OpenMetadata 2.0 also carries breaking changes, such as moving embedding credentials and rebuilding ingestion images, so budget engineers who can own upgrades and connector maintenance.
How to build the comparison with your own numbers
This sequence turns Purview's billing lines and your source inventory into a three-year cost model that compares Purview with a self-hosted OpenMetadata or DataHub deployment on the same assumptions. Each step names the output you should have before moving on.
Pull governed asset and DGPU history
Start with your own Microsoft Purview billing data. Export the governed asset counts and data quality processing unit (DGPU) consumption for the last several billing periods from the Azure cost reporting views your finance or cloud team can access. Your Azure account team or billing administrator can confirm which meters apply to your tenant. Record the monthly trend, not a single snapshot, because data quality schedules often drive DGPU consumption up or down over time. The output is a dated table of asset counts and DGPU use that a reviewer can trace back to invoices or cost exports.
List sources and connector coverage
Build a list of every data source Purview scans or should scan after a move, including Azure services, on-premises databases, SaaS tools and warehouses. For each source, note the owner, refresh frequency and whether an OpenMetadata or DataHub connector exists. Check connector names and versions against the current documentation in the OpenMetadata README and the DataHub README, since connector coverage changes between releases. Sources without a connector need a custom ingestion job, and that effort belongs in the staff time line later. The output is a source register with a coverage status for each row.
Choose OpenMetadata or DataHub for the scenario
Select one platform to model, or model both as separate scenarios. Compare the ingestion model, lineage needs, glossary and data quality requirements, and the operating skills your team already has. Confirm the current release line with each project's GitHub releases page before you fix a version in the model. Document which features your use cases require, such as column-level lineage or data product management, and which are optional. The output is a one-page selection record that names the platform and the features it must cover.
Size database, search and streaming footprint
Translate the documented minimums into a draft footprint. For OpenMetadata bare metal, the published 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. For DataHub on Kubernetes, the components are GMS, MAE and MCE consumers, the frontend, Kafka, a MySQL, PostgreSQL or MariaDB database, Elasticsearch and a graph index. Treat these as floors, then ask your platform team for production sizing guidance from the vendor or your implementation partner. The output is a component table with CPU, memory and storage per environment.
Price cloud or hardware per component
Price each component on the infrastructure you already run or plan to buy. Ask your cloud provider or hardware vendor for written quotes covering compute, managed database, managed search or Kafka, storage, backup and network egress, and separate production from non-production. Recurring items include compute hours, storage growth and backup retention. One-time items include hardware purchase, initial licensing for any operating system or database, and setup. Note what drives each line up: higher ingestion frequency, more sources, longer retention and additional environments. The output is a priced component sheet with one-time and recurring columns, and each line states its quote source.
Estimate ingestion, upgrade and support staff time
Estimate the people effort your team will carry. Include building and maintaining ingestion pipelines, handling connector changes, monitoring the platform, applying patch releases and planning major upgrades. OpenMetadata 2.0 lists breaking changes such as moving embedding credentials, a new Databricks auth format and migrating Great Expectations to 1.3 before upgrading, and DataHub upgrades run a system-update job that can reindex search. Estimate these as hours per month and state the assumption behind each figure. Pair the hours with the staff cost rate your finance team uses. Support tier is a separate line: compare the free community path with a paid support agreement from Collate or DataHub's vendor, or a retainer from an implementation partner, and ask each vendor for written terms. The output is a staff effort table with an explicit support tier decision.
Run a three-year view against Purview
Combine the Purview projection and the self-hosted model into a three-year table. Project Purview costs using the asset and DGPU trend from step one, with a labeled illustrative growth assumption that you change in sensitivity tests. Place one-time costs in year one and recurring costs by year. Show the self-hosted total with and without staff time so the reader can see the operating effort separately. Run at least a low, expected and high scenario, and label every scenario as illustrative. Before the model goes to procurement, request written quotes from Microsoft or your Azure reseller, the cloud provider and any implementation partner, then replace estimates with quoted lines. The finished model is a version-controlled workbook where every number traces to a quote, an invoice or a documented assumption.
What you take on when the catalog runs in your infrastructure
Running OpenMetadata or DataHub yourself moves upgrade work from a vendor to your platform team, and the cost of that work recurs for as long as the catalog is in use. OpenMetadata 2.0 is a breaking-change release: it moves embedding credentials into an llmConfiguration block, changes the Databricks auth format, requires custom ingestion images to be rebuilt for Python 3.12 and Apache Airflow 3.3.0, and asks you to migrate Great Expectations to 1.3 before upgrading. Each of those items needs an owner and a test run against a copy of your metadata store. Track the current point release, OpenMetadata 2.0.5 (October 8, 2026), and confirm the release cadence with the project before you set a patch window, since maintenance releases have followed about every one to two weeks.
DataHub upgrades carry a different kind of work. Its Helm chart runs a system-update job that applies schema changes and reindexes search when needed, so an upgrade can take longer and touch Elasticsearch or OpenSearch indices as well as the application. Plan for that job to run in a staging cluster first, and confirm the behavior for the specific chart version you deploy. Count DataHub 1.7.0.1 (September 3, 2026) as a current reference point, and check the DataHub releases page for what follows. On DataHub Core, SSO through OpenID Connect is also yours to configure and maintain, including the frontend server settings and the identity provider's client rotation, which the managed product handles through its interface.
Backups and monitoring are the parts most often left out of a cost estimate. Back up the relational store that holds metadata (MySQL or PostgreSQL for both products), and treat the search indices as rebuildable only after you have tested the rebuild time on your volume. Keep the ingestion connection secrets and the database credentials in a store you already back up and rotate. Monitor the components, not just the pods: database connections, search cluster health and disk, ingestion job failures, and the lag on Kafka for DataHub, which depends on it for streaming metadata changes. Ask your platform team who receives those alerts at 2 a.m. before you commit to a self-hosted design, because that answer determines whether the staff time in your comparison is a few hours a month or a standing role.
Questions buyers ask about Purview cost and self-hosting effort
How much does it cost to run a self-hosted OpenMetadata or DataHub?
The license is free under Apache-2.0, so the cost is the infrastructure and the people who run it. Infrastructure has three parts: the application servers, a relational database (MySQL or PostgreSQL), and a search service (Elasticsearch 9.x or OpenSearch 3.x for OpenMetadata, and Elasticsearch or OpenSearch for DataHub). DataHub also needs Kafka. For OpenMetadata, the bare metal documentation lists a minimum server 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. Those are minimums, not production sizing. For DataHub, the Docker quickstart requires 8 GB of RAM and the Kubernetes guide cites more than 7 GB to run DataHub and its dependencies on Minikube. Real production cost depends on source count, metadata volume, profiling frequency and high availability, so ask for a sized estimate against your own environment.
How long does a migration off Purview take?
The duration depends on the drivers, not a fixed number. The main ones are how many sources you rescan with new connectors, how much curated work must be carried over (glossary terms, owners, classifications, domains and data products), how many data quality rules must be rebuilt, and how many teams need to validate their assets. Lineage and custom Purview configuration usually need the most manual review. Check whether your Purview data quality rules are in scope, since they are rebuilt rather than exported. A written, fixed-scope plan from any implementation partner should list these items and their dependencies before work starts.
Can our team run a self-hosted catalog without outside help?
Yes, many teams do, but it helps to be honest about the skills required. Operating the platform means Kubernetes or bare metal administration, database and search operations, Kafka for DataHub, upgrade planning and backups. OpenMetadata 2.0 includes breaking changes, such as 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, so upgrades need a test environment. DataHub's Helm chart runs a system-update job during upgrades that applies schema changes and reindexes search when needed. A pilot on a single non-production source set will show your real staffing needs.
What staff time does a self-hosted catalog need after go-live?
Plan for recurring work in four areas: platform operations (patching, upgrades, monitoring, capacity), connector maintenance as source systems change, access and SSO administration, and the data stewardship that the catalog exists to support. Configuring OIDC SSO is operator work on self-deployed DataHub Core, where the frontend server must be configured by your team. Ask your team to estimate hours per month for each area, and compare that with what your current Purview administration consumes. Staff time is usually the largest recurring cost and the hardest to predict, so it should be stated explicitly in any comparison.
Does Collate or DataHub Cloud change the cost comparison?
Yes. Both are paid options that shift cost from your staff and infrastructure to a vendor. Collate offers managed OpenMetadata, commercial support and AI features. DataHub Cloud adds data quality monitoring, AI anomaly detection, compliance forms, access request workflows, a 99.5% uptime SLA and AWS PrivateLink, none of which are in the open-source edition. Compare each option against the same scope: the fees, your infrastructure costs, and the operating hours you would otherwise spend. Ask each vendor which features and SLA terms apply to your deployment before you compare totals.
How do we ask a partner for a fixed-scope quote?
Send a written scope before asking for a price. Include the list of sources and connector types, approximate governed asset counts from your current Purview inventory, the data quality rules and lineage you need, the SSO provider, the target hosting (cloud account, data center or air-gapped network), backup and retention requirements, the compliance evidence you need to prepare, and the support period you expect. Ask for deliverables, timelines, exclusions and acceptance criteria in writing. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms in your environment, works from fixed scopes agreed in writing, and does not publish a price list, so a quote follows from that written scope.
When staying on Purview is the right answer
Staying on Purview is often the right call when the estate is mostly Azure, the asset count is modest and the team has no appetite for running Kubernetes, search clusters and message queues. Purview Unified Catalog is a managed SaaS service that Microsoft operates, upgrades and secures, and it sits close to the Azure sources a Microsoft-centric organization already governs. Those operating savings are real even though they do not appear on a cost sheet: no one on the team patches Elasticsearch, sizes a database for a metadata store or plans an upgrade window. If your existing Microsoft agreement already covers the services you need, the commercial conversation may be simpler and the incremental cost of staying lower than a self-hosted build would add in staff time.
Staying is also defensible when governance work is light and the catalog is used mainly as a discovery and stewardship tool for a small group. In that case, confirm three things before you commit: the current governed asset count and data quality processing unit consumption as shown in your Azure billing, the number of sources that sit outside Azure and whether Purview's scanning covers them, and which people would own the catalog if a vendor-side change affected pricing or features. Write these down as a renewal checkpoint rather than an annual assumption, because consumption can grow faster than the catalog's use.
Keeping Purview is reversible, but only with a planned export. Purview has no one-click catalog export, so the exit cost grows with every glossary term, owner assignment and lineage relation you create. Before you decide, read How to export your catalog from Microsoft Purview only as a reminder that exporting is a project, then plan the sibling work: the export page, the Microsoft Purview vs OpenMetadata comparison and the migration guides for OpenMetadata or DataHub. Treat the decision as one you can revisit at each renewal, and keep a current inventory of glossary, ownership and classification data so that leaving remains an option.
How DeployOpen scopes a fixed-price catalog implementation
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source catalogs inside your own cloud accounts, data centers or air-gapped networks. For a move away from Microsoft Purview Unified Catalog, we start by agreeing in writing what the new catalog must cover, which sources it must reach and what the cost model will look like, before any build work begins.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope lists which Purview assets, glossary terms, owners and data quality rules move, and which are retired.
- We inventory source connectors and confirm which OpenMetadata or DataHub connectors cover each one.
- Scoping sizes the database, search and ingestion footprint against your asset counts, so the quote reflects real components.
How we build
- Deployment runs in your own infrastructure, on Kubernetes or on bare metal, as the agreed scope specifies.
- We configure ingestion schedules, single sign-on and access controls to match your identity provider and internal policies.
- Data quality tests and lineage checks are rebuilt and tested against sample assets from each source before cutover.
- Integration work covers the APIs and data products your downstream teams rely on, with each change documented.
How we hand over
- Handover includes architecture notes, runbooks for ingestion, upgrades and backups, and configuration records.
- Operators are trained on the catalog, including how to add sources, maintain glossary terms and review lineage.
- Each deliverable is listed in the written scope so you can confirm completion item by item.
- Controls and evidence are prepared for your compliance assessors, who make the final determinations, not DeployOpen.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover version upgrades, such as breaking changes listed in each release, and reindexing or migration tasks.
- Ask any vendor or provider for their support terms in writing, and ask us for the same before signing a scope.
- Request a quote from your written scope, which sets the price for your environment without a published price list.
