Choose Purview or OpenMetadata based on who should operate the catalog and where metadata must live
If you are facing a Purview renewal, a billing change or a residency requirement, the first question is who should run the catalog. Microsoft Purview Unified Catalog fits Azure-centric teams that prefer a Microsoft-managed SaaS catalog and are comfortable with billing per governed asset and per data quality processing unit. OpenMetadata fits teams that want self-hosted control, connector coverage beyond Azure, and the capacity to operate Kubernetes or bare metal. OpenMetadata is released under Apache-2.0, lists more than 130 connectors and documents production deployments on Kubernetes or bare metal, so the operating work sits with your platform team rather than with a vendor.
The decision turns on four factors. The first is operating capacity: who patches the database, search and ingestion services, upgrades releases and owns backups. OpenMetadata 2.0 also changed behavior that needs planning, including breaking changes to embedding credentials, Databricks authentication and custom ingestion images. The second is connector mix: list every source you must govern, count how many are outside Azure, and confirm each has an OpenMetadata connector at the version you run. The third is residency rules: decide whether metadata, which often includes sample values, owner names and lineage, may leave your network, and confirm with Microsoft where Purview stores it for your tenant. The fourth is the cost of staff time versus per-asset billing, which you can only compare with real numbers from your own asset counts and a written scope for the self-hosted build.
Before you choose, ask Microsoft to confirm in writing the current billing terms and where governed metadata is stored, and check OpenMetadata's connector list and deployment documentation against your sources and target platform. Then price the self-hosted option from a fixed scope that names the people who will own it. If you choose OpenMetadata and need the environment built, hardened and handed over, DeployOpen can scope that work in writing, but it does not decide the platform for you.
Which option fits which scenario
This table matches common operating scenarios to the platform that fits better, with the reason tied to how each product is hosted, billed and operated. Read it against your own estate, team skills and residency rules, since the answer changes when those change. The main takeaway: Purview suits teams that want Microsoft to run the service, while OpenMetadata suits teams that can operate Kubernetes or bare metal and want the metadata store under their own control.
| Scenario | Better fit | Reason |
|---|---|---|
| Azure-only estate, no in-house platform team | Microsoft Purview Unified Catalog | Microsoft runs the SaaS service. Your team avoids operating the database, search tier and upgrades that self-hosting requires. |
| Multi-cloud or on-premises sources | OpenMetadata | OpenMetadata lists 130+ connectors across warehouses, BI, pipelines and ML. Confirm coverage for your specific sources first. |
| Strict data residency | OpenMetadata | The metadata store, search and ingestion run in infrastructure you choose. Confirm where your Purview tenant stores catalog metadata. |
| Existing Purview governance workflows | Microsoft Purview Unified Catalog | Approvals, roles and data products already built in Purview would need rebuilding in OpenMetadata. Plan that effort before deciding. |
| Team that wants to own the metadata store | OpenMetadata | Apache-2.0 code, REST APIs and a Python SDK let you control the database, indexes and scripted exports. |
| Evaluating before committing | OpenMetadata | Docker Compose supports an evaluation install. Production sizing and the Kubernetes or bare metal setup can follow once the pilot proves out. |
Where metadata lives and who controls access
Purview Unified Catalog keeps the catalog in Microsoft's service, so the control plane, upgrades and most access paths sit with Microsoft and your Entra tenant. OpenMetadata moves those decisions into your cloud account or data center, where you own the network path, the identity provider and the evidence that auditors will ask for.
Where the catalog runs
Purview Unified Catalog is a SaaS service on top of the Data Map, so the catalog service and its metadata store are operated by Microsoft. OpenMetadata runs in your own AWS, Azure or Google Cloud account, on-premises Kubernetes or bare metal, and you choose the region, the network boundary and the backup location. Confirm where each metadata store (database, search index, ingestion logs) will physically sit, because the catalog holds schema names, sample-derived profiles and lineage that many regulators treat as sensitive.
Air-gapped and restricted networks
A self-hosted OpenMetadata deployment can run on a network with no route to the internet, provided container images, Helm charts and Python packages are mirrored internally. Purview depends on Microsoft-hosted endpoints for the catalog itself, so an isolated environment is a different architecture. Check with your own team and with Collate which ingestion images, connectors and AI features need outbound access before you promise an offline deployment.
Identity and single sign-on
Purview authenticates users through Microsoft Entra ID, and access to collections and roles is granted through Purview role assignments. In OpenMetadata, you decide how users sign in and how group membership maps to roles, so the identity provider you connect becomes part of the control design. Confirm which OIDC or SAML options your version supports, how service accounts for ingestion are issued and rotated, and whether deprovisioning in your directory removes catalog access promptly.
Who holds the data access controls
Purview's permissions model lives in Azure role assignments and Data Map collections, and changes depend on how your Azure tenant is administered. With OpenMetadata, the access rules for metadata, the ingestion service accounts and the database credentials are in your hands and your change process. Map every role to a named owner, record who can edit glossary terms and classifications, and test that a removed user cannot still reach sample data or lineage through the API.
Evidence you must produce yourself
DeployOpen can prepare controls, configuration baselines and evidence collection for a compliance assessment, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work. With a self-hosted catalog, expect to produce access review records, change logs for deployments and upgrades, backup and restore test results, and network and encryption configuration evidence yourself. Ask your auditor which of these they will sample before you design the logging.
Operating responsibility for upgrades
Purview's service updates are applied by Microsoft, which removes the upgrade calendar from your team. OpenMetadata is released frequently, and release notes for 2.0 list breaking changes such as credential format moves and Python image rebuilds. Your team or an implementation partner must plan upgrades, test them against your sources and keep a rollback path. Ask your vendor for a supported upgrade path and written scope before you commit to self-hosting.
Deployment paths for self-hosted OpenMetadata
OpenMetadata documents production deployments on Kubernetes using Helm charts, on Amazon EKS, Azure AKS, Google GKE or an on-premises Kubernetes cluster. This path suits organizations that already run clusters and have platform engineers who manage ingress, storage classes, secrets and upgrades. The surrounding services, a MySQL or PostgreSQL database and Elasticsearch 9.x or OpenSearch 3.x, must also be sized and backed up.
- Database and search: Plan for MySQL 8.0.42 or later, or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x, either inside the cluster or as managed services in your own cloud account.
- Minimum sizing: The published minimum for the OpenMetadata server is 2 vCPUs, 4 GB RAM and 20 GB storage, and the database and search services each need at least 2 vCPUs, 2 GB RAM and 30 GB storage.
- Ingestion workloads: Scheduled connector runs execute as separate jobs, so size node pools for peak ingestion, not only for steady browsing.
- Operating tasks: Helm chart version pinning, secret rotation, persistent volume snapshots, ingress and TLS, and cluster patching all become your responsibility.
- Upgrades: Review the 2.0 breaking changes, including the embedding credential move and Great Expectations 1.3 migration, before rolling a chart version forward.
Confirm the exact chart version, supported Kubernetes versions and sizing for production with OpenMetadata's deployment documentation and your own load profile.
The bare metal path installs OpenMetadata directly on Linux hosts without Kubernetes. It fits teams that prefer fewer moving parts, run on virtual machines or in restricted environments where a cluster is not available. The trade-off is that process supervision, service restarts, log rotation and failover are handled by your own tooling and runbooks.
- Runtime: The bare metal prerequisites include Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x.
- Minimum sizing: Start from 2 vCPUs, 4 GB RAM and 20 GB storage for the server, with at least 2 vCPUs, 2 GB RAM and 30 GB storage each for the database and search hosts.
- Host separation: Separate hosts for the application, database and search make capacity planning and restore testing clearer, though a single-host layout is possible for small evaluations.
- Operating tasks: Java and OS patching, database backups and point-in-time recovery, search index rebuilds, and TLS certificate renewal sit with your operations team.
- Configuration: Keep server configuration under version control and check the security deployment guidance before exposing the service to users.
Confirm the supported operating system versions, the exact Java and database patch levels, and how the upgrade procedure handles schema changes on your chosen release.
Docker Compose is documented for evaluation and local trials, not for production. It brings up OpenMetadata and its dependencies on one machine so a team can test connectors, lineage and glossary workflows before committing to a production design. Treat a Compose stack as a sandbox that informs the production choice.
- Use case: Connector testing, a proof of concept with sample sources, and training for data stewards are the typical fits.
- Not for production: The deployment documentation reserves production guidance for Kubernetes and bare metal, so do not place governed metadata or access controls for regulated data on a Compose stack.
- Data handling: Sample or copied metadata in a trial should be deleted or migrated deliberately, since a Compose volume is easy to forget.
- Resource planning: A single host must carry the application, database and search services together, so measure memory use under your connector load before drawing conclusions about production sizing.
- Transition: Reuse the connector configuration and ingestion definitions you tested, but rebuild secrets handling and network policy for the production path.
Confirm the current Compose file and image tags with the OpenMetadata deployment documentation before any evaluation begins.
What drives cost on each side
Purview bills on governed assets and data quality processing units, while a self-hosted OpenMetadata deployment bills on infrastructure, operations and people. The cards below separate the recurring meters from the one-time and ongoing costs you carry yourself, and list what to request before comparing totals.
Governed asset count
Purview Unified Catalog bills on the number of governed assets, so the count of tables, files, dashboards and other objects you bring under governance is the main recurring driver. Scope decisions such as ingesting whole databases versus curated domains move this number more than any other choice. Ask Microsoft exactly how an asset is counted, how often the count is measured, and whether rescans of unchanged assets add to it.
Data quality processing units
Data quality checks in Purview consume data quality processing units, so the volume and frequency of rules across your estate drive a second recurring meter. Profiling a large table on a tight schedule costs more than a few weekly rules on curated tables. Ask for the DGPU rate, the unit consumption of your planned rule set, and the monthly consumption forecast, using the figures on Microsoft's own pricing pages.
Database and search footprint
A self-hosted OpenMetadata deployment needs a relational database and a search service, and the bare metal prerequisites name MySQL 8.0.42 or later or PostgreSQL 15 or later, plus Elasticsearch 9.x or OpenSearch 3.x. Both are sized separately from the application server, so their storage grows with asset count, profiling history and lineage volume. Budget for managed or self-run versions, backups and replicas.
Ingestion compute and storage
Connector runs for warehouses, BI tools and pipelines need compute, and profiling and sampling add load on the source systems and the ingestion host. Minimum sizing starts at 2 vCPUs, 4 GB RAM and 20 GB storage for the server, with the database and search services each at least 2 vCPUs, 2 GB RAM and 30 GB storage. Real production sizing depends on your source volume and schedule, so test it in a staging environment before committing to a size.
Upgrades and maintenance work
OpenMetadata 2.0 moved ingestion images to Python 3.12 and Apache Airflow 3.3.0, changed embedding credentials into an llmConfiguration block, and required migrating Great Expectations to 1.3 before upgrading. Each release therefore carries engineering time for rebuilding custom ingestion images and testing connectors. Purview upgrades are handled by Microsoft, so this cost is the main shift in who does the work.
Support and staff time
Purview includes the service and its operation under the subscription model, while self-hosting moves uptime, backup, security patching and on-call into your staff budget or a support contract. Collate offers commercial support and managed OpenMetadata, and DeployOpen offers fixed-scope implementation and retainers, but neither replaces an internal owner. Ask any partner for the scope, response commitments and the hours your team must still staff.
What a move from Purview to OpenMetadata involves
The sequence below moves a Purview Unified Catalog estate to a self-hosted OpenMetadata instance in stages, so each source, glossary term and data quality rule is confirmed in the new catalog before users leave Purview. Because Purview has no one-click export, the work is part rescanning and part rebuilding.
Inventory sources, connectors and curated metadata
Your data governance lead and the team that owns Purview list every registered source, scan schedule, glossary term, data owner, classification, data product and data quality rule in Unified Catalog. Map each source to an OpenMetadata connector, noting any source with no connector so it can be handled through the REST API or the Python SDK instead. The output is a written inventory with a connector or method next to every source, reviewed and signed off by the owners of each domain.
Stand up a non-production OpenMetadata
Your platform engineering team deploys OpenMetadata in a non-production environment, using the Helm charts on your Kubernetes cluster or the bare metal path if you do not run Kubernetes. Check the prerequisites first: Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x. Confirm the sizing in the vendor documentation for your expected volume. The step is done when the UI, the search index and the ingestion framework all work with a test source.
Re-ingest sources with OpenMetadata connectors
Your data engineers configure ingestion pipelines in the new instance for each source in the inventory, starting with the lowest-risk ones. Connectors pull in tables, columns, dashboards and pipelines directly from the systems, so Purview scan results are not copied across. Set up ingestion schedules and confirm that owners and descriptions are not overwritten in a way that loses curated content. The step closes when each source shows the expected asset counts and a second run produces no unexpected changes.
Carry over glossary terms, owners and classifications
Your governance team exports glossary terms, ownership and classification data from Purview through its Atlas-compatible Data Map APIs, since Purview offers no one-click catalog export. Shape the output into the formats OpenMetadata imports, then load and review it with the stewards who own those terms. Expect manual cleanup where Purview's model does not map cleanly to OpenMetadata glossaries, classifications and domains. The step is done when a sample of terms and owners matches the approved list in the inventory.
Rebuild data products and data quality tests
Your data quality engineers and domain owners recreate data products and data quality rules in OpenMetadata, using its data quality tests, profiling and freshness checks. Review profiler settings, since OpenMetadata 2.0 made Dynamic Sampling the profiler default, and confirm each test against the rule it replaces. Keep Purview rules running in parallel until the new results agree with them. The step closes when each critical data product has its tests passing and an owner who accepts the results.
Validate lineage end to end
Your data engineers compare lineage in OpenMetadata against the lineage Purview recorded for key tables, dashboards and pipelines. Check table, column, dashboard and pipeline lineage, and confirm that OpenLineage events from your pipelines are arriving if you use them. Document any gaps where Purview lineage came from a source that OpenMetadata does not cover, and decide how each gap will be closed. The step is done when the lineage gaps are either fixed or recorded as accepted risks.
Cut over users, access and integrations
Your identity team connects OpenMetadata to your SSO provider and assigns roles that match the access model in Purview. Update API clients, scripts and any downstream tools that called Purview endpoints to use OpenMetadata APIs. Run a training session for stewards, analysts and data owners, then announce the cutover date. The step closes when users sign in through SSO, the old integrations are switched off, and the support contact for the new platform is named.
Retire Purview and keep the evidence
Once the parallel run is accepted, your team stops scans in Purview, exports a final record of its metadata and decisions for your archive, and removes Purview resources so billing stops. Confirm the removal with your cloud finance team, since governed asset and DGPU charges depend on the configuration. Keep the inventory, validation results and sign-offs with your records, as these are the evidence that the migration preserved governed metadata. The step is done when Purview is no longer in use and the archive is stored under your retention rules.
Questions buyers ask before choosing OpenMetadata
How much effort does a migration from Purview to OpenMetadata take?
The effort is driven by how many sources you connect, how much curated metadata you carry over, and how many data quality rules you rebuild, so the answer is different for every estate. The largest items are usually re-ingesting each source with an OpenMetadata connector, mapping Purview glossary terms, owners and classifications to OpenMetadata equivalents, and recreating data products and quality tests. Ask any provider to break the plan into those workstreams and to state which of them depend on your own data owners being available for review. Duration should come from your written scope, not from a general estimate.
Can an internal team run OpenMetadata without a vendor?
Yes, the software is Apache-2.0 licensed and can be run entirely by your own staff, but the operating work is real and continuous. Your team would own the Kubernetes or bare metal hosting, the database and search services, ingestion schedules for each connector, access control and backups. Teams often start with a small number of sources and expand once the operating routine is stable. Confirm internally whether you have the on-call coverage and the platform skills to keep the catalog available for business users.
What skills does a team need to operate OpenMetadata?
The team needs platform skills for the deployment, data engineering skills for connectors, and governance skills for the metadata itself. On the platform side, the bare metal prerequisites include Java 21, a supported MySQL or PostgreSQL database, and Elasticsearch 9.x or OpenSearch 3.x, so people who run those services will be needed. Ingestion work involves Python and the connector configuration for each source. Programmatic access is available through REST APIs, a Python SDK, TypeScript packages and Java libraries, which helps when you automate glossary or ownership updates.
How do upgrades work given the OpenMetadata 2.0 breaking changes?
Upgrades need a planned change window and a review of the release notes for each version you cross, because 2.0 introduced breaking changes. The 2.0 release notes list 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. Maintenance releases from 2.0.1 to 2.0.5 arrived about every one to two weeks, so keep a routine for testing them in a non-production environment. Confirm with your team which of your custom connectors or integrations are affected before scheduling the move.
What does Collate add beyond open-source OpenMetadata?
Collate is the company behind OpenMetadata and offers managed OpenMetadata, commercial support and AI features on top of the open-source project. The open-source edition already provides the catalog, lineage, data quality, glossaries and APIs described in the project documentation. Commercial value usually lies in service levels, vendor-run upgrades and hosting, and features Collate chooses to keep outside the Apache-2.0 release. Ask Collate to list in writing which features are excluded from the open-source edition and what support terms apply, so you compare like with like.
Does Purview classic consent or billing change affect this decision?
It can, because the choice between staying with Purview and moving to self-hosted OpenMetadata depends on how your Purview billing is structured. Existing Azure Purview customers must consent to pay-as-you-go billing to use Unified Catalog, or remain on the classic Data Catalog, so the commercial terms you accept shape your recurring cost. Compare the billing components directly, governed assets and data quality processing units, against your own infrastructure and staff time. Confirm your current consent status and renewal date with Microsoft before you decide.
What should a services partner include in a fixed-scope quote?
A fixed-scope quote should list the sources in scope, the deliverables, the environment, the acceptance criteria and the dates agreed in writing before work starts. DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted platforms in your own infrastructure, and most engagements are fixed-scope. Ask for the hosting model (Kubernetes or bare metal), the backup and restore approach, the handover of documentation, the testing responsibilities, and what ongoing support is offered as a separate retainer. DeployOpen does not publish a price list, so a quote follows from the written scope.
What running OpenMetadata asks of your team
Running OpenMetadata is an ongoing job, not a one-time install. The project has shipped 2.0.0 on August 24, 2026, followed by maintenance releases 2.0.1 through 2.0.5 at roughly one- to two-week intervals, so your platform owner should plan for a recurring upgrade rhythm rather than an occasional project. Each upgrade needs a staging rehearsal, and the 2.0 breaking changes are a good test case: embedding credentials move into an llmConfiguration block, Databricks authentication uses a new format, custom ingestion images must be rebuilt for Python 3.12, and Great Expectations must be migrated to 1.3 before the upgrade. Read the release notes for each version before you schedule it, and assign one named person to own that reading and the change record.
Day-to-day operations sit around the database and the search index. OpenMetadata keeps its metadata in MySQL or PostgreSQL and its search index in Elasticsearch or OpenSearch, so backups must cover both and you must test restores, since a rebuilt search index alone does not recover curated glossary terms, owners or domain assignments. Your team also owns monitoring of the server, database, search nodes and ingestion pipelines, plus the Airflow-based ingestion schedules. Connector maintenance is continuous: each warehouse, BI and pipeline source has credentials that rotate, and connector behavior changes across versions. Access control is yours to configure, including who can edit glossaries, classifications and data products, and how service accounts and API tokens are issued and revoked.
Before you commit, confirm capacity in writing. Ask which people will hold the upgrade, backup, monitoring and connector duties, how many hours per month each role realistically needs in your environment, and who covers absences. The OpenMetadata deployment documentation and the OpenMetadata security documentation are the natural next reads for mapping these duties. If your team cannot staff these roles, the cost of a managed option, either from Collate or from a DeployOpen retainer scoped in writing, should be compared against the staff time you would otherwise carry.
How DeployOpen helps you evaluate, implement or migrate
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a move from Microsoft Purview to OpenMetadata, we start with a written scope that fits your sources, governance workflows and operating model, then build and hand over the environment.
How we scope
- Inventory the Azure and non-Azure sources that need OpenMetadata connectors before any build starts
- Record which glossary terms, owners, classifications and data products must carry over
- Agree in writing which data quality rules and lineage views are in and out of scope
- Confirm the target deployment, such as Kubernetes or bare metal, against your infrastructure standards
How we build
- Deploy OpenMetadata with its database and search dependencies sized to your confirmed requirements
- Configure ingestion, lineage and OpenLineage event integration for the agreed sources
- Rebuild data quality tests, glossaries and domains in OpenMetadata and check them against the agreed scope
- Test access controls, authentication and API credentials as part of hardening
How we hand over
- Deliver runbooks for ingestion schedules, upgrades, backups and restore procedures
- Document the mapping from Purview assets, terms and owners to OpenMetadata entities
- Walk your platform and governance teams through daily operation and API use
- Provide evidence of configuration and controls for your internal or external compliance assessments
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Plan OpenMetadata upgrades against the release notes, including any breaking changes
- Keep connector and ingestion configurations current as your data sources change
- Ask for a quote based on the written scope, since DeployOpen does not publish a price list
