Replacing Informatica Data Catalog with a self-hosted open-source catalog
If your team licenses Informatica's catalog and faces a renewal, a cloud move or a data residency requirement, the main self-hosted options for metadata discovery, lineage, glossary and data quality are OpenMetadata and DataHub. Both are Apache-2.0 licensed and can run in your own Kubernetes cluster or on bare metal. The catalog can be replaced independently of PowerCenter, so you do not need to move your ETL first. Start by inventorying which sources the catalog actually scans today, such as warehouses, BI tools and pipelines, and confirm that the connectors you need exist in the candidate platform's current release before you commit.
The main gap is CLAIRE. Informatica describes CLAIRE as the AI layer that assists stewardship, so its suggestions and automated classification have no direct equivalent in either project. Plan to rebuild that work as explicit rules, classification and tagging policies, approval workflows for glossary terms and ownership assignments, and manual curation by named data stewards. Ask each vendor which automated classification and tagging features are included in the open-source edition and which sit in the commercial offering, and test those features on a sample of your own data before you retire the Informatica service.
Operating either platform is your responsibility once it is in your environment. OpenMetadata documents Java 21, a supported database, and Elasticsearch 9.x or OpenSearch 3.x as bare metal prerequisites, and DataHub depends on Kafka, a relational database, and a search and graph index, so budget for the people who will patch and upgrade those components. Read the breaking-change notes for each upgrade before you apply it. For OpenMetadata 2.0, that means reviewing the embedding credential changes and the Python 3.12 image rebuild, and for DataHub, expecting the Helm system-update job to run on upgrades. Confirm your support needs with each vendor's commercial arm or an implementation partner, because open-source licensing does not include a support contract.
Which open-source option covers each catalog capability
This table maps the main capabilities of Informatica Data Catalog to OpenMetadata and DataHub, with notes on where each platform covers the need and where configuration or custom work is required. Read each row against the exact sources in your estate, since connector coverage decides how much of your metadata arrives without custom code. The main takeaway is that discovery, lineage, glossary and quality are well covered, while CLAIRE-style AI stewardship has no direct equivalent and needs deliberate design.
| Capability | OpenMetadata | DataHub |
|---|---|---|
| Multi-type discovery | More than 130 connectors for warehouses, BI tools, pipelines and ML platforms. Confirm each source in your estate is covered before planning. | More than 150 integrations listed in the README, including Snowflake, BigQuery, Databricks, dbt, Looker and Tableau. Confirm unstructured or niche sources separately. |
| Metadata management | Tables, columns, dashboards, pipelines, glossaries, classifications and domains are native objects. Custom intake forms were added in 2.0. | Push and pull ingestion feed a central metadata service. Ownership, usage and schema statistics are collected per dataset. |
| Lineage visualization | Table, column, dashboard, pipeline and metric lineage, with OpenLineage event integration for pipelines that emit it. | Column-level lineage is listed as a feature. Confirm lineage depth for your specific ETL tools, including any PowerCenter-era jobs. |
| Data quality assessment | Data quality tests, profiling, freshness checks and Dynamic Sampling as the profiler default. Great Expectations 1.3 is required for 2.0 upgrades. | Data quality assertions and monitoring are listed. Test coverage depends on how your teams author and maintain assertions. |
| AI-assisted stewardship (CLAIRE-style) | Gap: no direct equivalent to CLAIRE. Plan for MCP-based automation, the Context Center and custom workflows, and confirm what your team will build. | Gap: no direct equivalent to CLAIRE. Plan for custom automation through the API and ingestion pipelines, and define stewardship rules yourselves. |
| Access and programmatic control | REST APIs, a Python SDK, TypeScript packages and Java libraries support scripted stewardship and bulk updates. | Programmatic access and ingestion frameworks support scripted updates. Confirm the API surface you need for bulk stewardship. |
| Single sign-on | Covered by OpenMetadata security configuration. Confirm the identity provider and group mapping your organization requires. | OIDC SSO works with providers such as Google, Okta and Azure AD. On self-deployed DataHub Core, the operator configures the frontend. |
OpenMetadata or DataHub: which fits which team
Both projects are Apache 2.0 and cover the core catalog job of discovery, lineage, glossary and quality checks that Informatica Data Catalog and CLAIRE provide. They differ mainly in how many services you run, how they expose metadata to users, and which team skills they assume.
OpenMetadata: broad connectors and APIs
OpenMetadata is Apache 2.0 licensed and lists more than 130 connectors for warehouses, BI tools, pipelines and ML platforms. It covers table, column, dashboard, pipeline and metric lineage with OpenLineage events, plus data quality tests, profiling, glossaries, classifications and domains. It exposes REST APIs, a Python SDK, TypeScript packages and Java libraries. Check that your sources are on the connector list before you commit, and confirm which features Collate's commercial edition adds.
OpenMetadata: bare metal or Kubernetes
For a bare metal install you need Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x. Production deployments are documented on Kubernetes (EKS, AKS, GKE or on-premises clusters) and on bare metal. Teams with a platform group and existing Java and database operations usually find the single-application footprint easy to run. Ask your team who owns search index upgrades, since 2.0 changed several ingestion and credential settings.
DataHub: Kafka-based metadata architecture
DataHub centers on a metadata service (GMS) that streams metadata changes through Kafka, with MySQL or PostgreSQL storage and Elasticsearch or OpenSearch for search. Its Kubernetes guide lists GMS, the MAE Consumer, the MCE Consumer and the Frontend, plus a graph index on Neo4j or Elasticsearch. This suits teams that already run Kafka and want push-based metadata events across many tools. Plan for the extra operating load of a streaming tier, not just the web application.
DataHub: Helm-based Kubernetes operations
DataHub is deployed on Kubernetes with Helm charts from its own repository, plus a separate prerequisites chart for dependencies. Its guide notes that more than 7 GB of RAM is needed to run DataHub and its dependencies on Minikube, and the Docker quickstart needs 8 GB. Upgrades run a system-update job that applies schema changes and reindexes search when needed. Teams comfortable with Helm and Kafka operations tend to favor DataHub, and they should test upgrades in a non-production cluster first.
Choose by team profile
Pick OpenMetadata when a small platform or data team wants a single service, a strong set of native connectors and SDKs for in-house automation. Pick DataHub when a larger platform team already operates Kafka and Kubernetes and wants event-driven metadata across many systems. In both cases, confirm SSO requirements early: DataHub Core requires the operator to configure OIDC on the frontend, while DataHub Cloud enables it through its interface.
Running OpenMetadata or DataHub on your own infrastructure
Kubernetes is the route both platforms document for production. OpenMetadata documents production deployments on AWS EKS, Azure AKS, Google GKE and on-premises clusters, and Docker is documented for local trials. DataHub is deployed with Helm charts from the acryldata/datahub-helm repository, paired with a separate prerequisites chart that provisions its dependencies. The DataHub Kubernetes guide lists four main components (GMS, the MAE Consumer, the MCE Consumer and the Frontend) that need Kafka, a MySQL, PostgreSQL or MariaDB database, Elasticsearch for search and a graph index on Neo4j or Elasticsearch.
- Dependency footprint: DataHub needs Kafka, a relational database, a search index and a graph index running before the application charts are useful. Plan who operates each one.
- Upgrades: The DataHub Helm chart runs a system-update job on upgrades that applies schema changes and reindexes search when needed. Test this job against a copy of production metadata first.
- Local evaluation: The DataHub guide says more than 7 GB of RAM is needed to run DataHub and its dependencies on Minikube. Treat that as the floor for a laptop trial, not a production figure.
- Managed Kubernetes services: Confirm with your cloud team which managed Kafka, database and search services your policies allow, since each choice changes the operating model.
- Sizing: Production node counts and resource requests must come from your own load tests, measured against your metadata volume, ingestion schedule and user count.
Before approving a cluster design, ask your platform team to write down the backup, restore and upgrade steps for every stateful dependency.
OpenMetadata can run on bare metal without Kubernetes, which suits teams that do not operate a cluster for this workload. The bare metal documentation lists Java 21 as the runtime prerequisite, MySQL 8.0.42 or later or PostgreSQL 15 or later as the database, and Elasticsearch 9.x or OpenSearch 3.x as the search service. Those versions are the documented minimums, so confirm them against the release you plan to install before you build the hosts.
- Runtime: Install Java 21 on the server and keep it under the same patch process as the rest of your estate.
- Database: Choose MySQL 8.0.42 or later or PostgreSQL 15 or later, and plan regular backups with tested restores.
- Search: Run Elasticsearch 9.x or OpenSearch 3.x on separate hosts from the application where your sizing allows.
- Minimum sizing: The 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. These are floors for a small instance, not a guide for production.
- Process management: Bare metal means your team writes the service units, log rotation, certificate handling and failover procedure that Kubernetes would otherwise provide.
Confirm the exact versions in the bare metal guide and your chosen release notes, and ask your team to load test the sizing with realistic ingestion and search traffic before go-live.
Where the catalog must run without outbound internet access, both platforms still need their container images, packages, connector libraries and documentation staged inside your network. The supplied facts do not describe an offline installation procedure for either platform, so treat air-gapped support as something to confirm with each vendor and test in a staging environment. The ingestion side also matters: connectors reach source systems such as warehouses, BI tools and pipelines, so the network paths from the catalog hosts to each source need to be documented and approved.
- Artifact staging: Mirror container images, Helm charts and Python or Java packages into an internal registry or repository before installation.
- Connector reachability: List every source system each ingestion job reads and confirm the firewall rules that allow it.
- Authentication: DataHub Core requires the operator to configure OpenID Connect single sign-on in the frontend server. OpenMetadata's security documentation covers its own authentication options, so confirm which identity provider you will connect to.
- Update path: Establish how patches reach an isolated environment, since upgrade windows will be slower than in connected networks.
- Evidence: Keep records of what was installed, from which mirror and at which version, for your change management and audit files.
Ask each vendor or community channel for documented offline install steps before committing to a design.
What CLAIRE-driven automation leaves to configure by hand
AI-assisted stewardship, automated classification and suggested relationships in Informatica do not carry over as a product feature. Informatica describes CLAIRE as the layer that drives discovery, classification and steward suggestions inside its catalog. In a self-hosted stack, those suggestions have to be replaced by rules and by people. Start by listing what your team currently accepts from CLAIRE without review, because that list is the minimum scope of manual work. Ask Informatica which suggestions were automatic and which required steward approval, and check whether any of them depended on Informatica-specific metadata that will not import.
Ownership assignment is the first item to configure. In OpenMetadata, owners and domains are set on tables, dashboards and pipelines, and they drive who gets notified when quality tests fail. In DataHub, ownership is applied to datasets and is queried through the same metadata model that feeds the business glossary. Glossary term curation is the second. Both catalogs provide a glossary, but someone must write definitions, approve terms and link them to columns. Classification rules, such as tagging columns that hold personal or payment data, must be written as explicit patterns and reviewed against sample data, since no tool will reproduce CLAIRE's inferred labels for you. Data quality tests and alerting follow the same logic: OpenMetadata offers data quality tests, profiling and freshness checks, and DataHub offers assertions and monitoring, but each test, threshold and alert route is a decision your data owners make.
OpenMetadata 2.0 enables MCP by default and adds the Context Center, which changes how AI tools can read catalog content. Before you plan around any AI feature, confirm in your target version what it does, what data it sends and where it runs, and whether it can be disabled. The OpenMetadata 2.0 release notes list these changes, and the OpenMetadata 2.0 release notes are the starting point for that check. Stewardship workflows should be defined before rollout: who approves a new glossary term, who can change a classification and how a failing quality test escalates. Those workflows are configuration and governance work, and they recur every time the catalog grows.
Moving catalog metadata, glossaries and lineage
This sequence moves the catalog's inventory, glossary, ownership and lineage into OpenMetadata or DataHub in a controlled order, so each stage is checked before users depend on it. The result is a validated catalog in a non-production environment that is ready for a staged cutover.
Export the Informatica catalog inventory and glossary
The data governance lead and a catalog administrator pull every asset list, business glossary term, classification, owner assignment and stewardship record that the current Informatica Data Catalog holds. Confirm first which export formats your Informatica version and license offer, because the supplied facts do not cover automatic conversion of catalog objects. Expect manual extraction or CSV-style lists for some objects. The step is done when each glossary term and owned asset is recorded in a source-controlled inventory with a named owner who will review it.
Select the source connectors and priority sources
The platform owner and the data architects rank the systems that feed the catalog, such as warehouses, BI tools, transformation jobs and orchestration tools, by how often users search them and how much lineage depends on them. Check each candidate against the connector lists for OpenMetadata and DataHub, which are published in each project's repository, and note any system that needs a custom connector. Record a short list of connectors and the credentials each one needs. The step is done when every priority source has a confirmed connector and a service account approved by the security team.
Stand up the platform in a non-production environment
The platform team deploys the chosen catalog in a separate environment inside your own infrastructure, using the Kubernetes or bare metal path that matches your standards. For OpenMetadata, provision Java 21, a supported MySQL or PostgreSQL version, and Elasticsearch 9.x or OpenSearch 3.x, with the minimum sizing in the bare metal documentation as the starting point. For DataHub, install the Helm charts and the prerequisites chart, including Kafka, the database and search. The step is done when the services start cleanly, the admin account works, and backups of the metadata store have been tested once.
Run ingestion for the highest-value sources
The catalog engineers configure ingestion for the priority connectors and run it against the non-production copies of those sources, starting with the systems that carry the most business-critical lineage. Record the run results, including failed assets, schema mismatches and permission errors. Where a connector is missing, document the gap and the workaround. The step is done when each priority source shows its tables, columns, dashboards or pipelines in the catalog and the ingestion logs show no unresolved errors for those sources.
Import glossaries and rebuild ownership and stewardship
The data stewards recreate the business glossary terms, domains and classifications from the exported inventory, then assign owners and stewards to each asset. This work is manual unless your export is machine-readable, and it is the part most likely to need business sign-off. Agree in writing who approves glossary changes and who may edit ownership. The step is done when every glossary term has a definition and owner, and every priority asset has a named owner that the steward has confirmed.
Validate lineage against known data flows
The data engineers choose a set of known flows, such as a report that depends on a warehouse table fed by a transformation job, and compare the lineage shown in the catalog with the documented design. Check table, column and pipeline lineage separately, because ingestion may capture some links and miss others, particularly for jobs that are not yet connected through supported lineage integrations. Record each mismatch and decide whether to fix the connector configuration or add the link manually. The step is done when the agreed flows match the documented design, and the open gaps are listed with an owner.
Test data quality checks and access controls
The data quality owners reproduce the important existing checks in the new platform, using the platform's native tests or assertions, and confirm that results appear against the right assets. The security team reviews role mappings and access to sensitive classifications. Confirm with your own environment and the vendor documentation which quality and monitoring features each deployment includes. The step is done when the critical checks run and report correctly and the role model has been signed off.
Cut over users and single sign-on
The identity team configures single sign-on through an OpenID Connect provider, and the platform owner sets the frontend configuration on a self-deployed DataHub or the matching settings for OpenMetadata. Users are then moved in groups, with a short period where the Informatica catalog stays read-only for reference. Confirm the SSO settings with a test user before any group is switched. The step is done when all planned users sign in through SSO, search and lineage work for them, and the decommissioning date for the old catalog has been approved by the business owner.
Cost components of a self-hosted catalog
The Informatica Data Catalog line item is only one cost to compare. Start by pulling the current order form or renewal notice, which shows the license or subscription term, the metered units if the catalog is billed through IDMC consumption, and any bundled services. On the self-hosted side, the recurring costs are infrastructure, support and staff time. The one-time costs are planning, installation, connector configuration, SSO and security hardening, and the first load of metadata. Ask a DeployOpen or other implementation partner to split its written quote into these buckets so the two options can be compared line by line. Infrastructure is the cost most sensitive to design. For OpenMetadata, the bare metal documentation sets minimum sizes for the server, the database (MySQL or PostgreSQL) and the search service (Elasticsearch or OpenSearch), and production deployments on Kubernetes add cluster capacity on top. DataHub needs Kafka for streaming metadata changes, a relational database, a search index and a graph index, and its Kubernetes guide adds the GMS, consumers and frontend. Ask your platform team to price each of these as separate workloads in your own cloud account or data center, including backups and non-production copies.
Some costs arrive later and recur. Upgrades are the largest. 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. DataHub's Helm chart runs a system-update job on upgrades, so the upgrade window needs database and search capacity as well. Budget internal engineer time for each release cycle, and for connector maintenance, since Informatica's connectors are updated by the vendor and self-hosted connectors are updated by your team or your partner.
In the written quote, ask for each deliverable and its acceptance criteria, the fixed scope boundary, the SSO and hardening work, the handover documentation, and the support terms after go-live. Ask whether the price covers the first upgrade, and what a retainer for ongoing support would include. Confirm whether the catalog's commercial add-ons, such as OpenMetadata's premium support from Collate or DataHub Cloud, are being compared or excluded. Finally, record internal staff time as its own line, because it is often the largest recurring cost and is the easiest to leave out of the comparison.
Questions buyers ask before replacing Informatica Data Catalog
How much effort does replacing Informatica Data Catalog take?
The effort depends mostly on how many sources you connect, how much custom metadata and glossary content you carry over, and how many lineage paths you need to rebuild. Informatica Data Catalog is described as an AI-powered product covering discovery, metadata management, lineage, data quality assessment and CLAIRE-assisted stewardship. CLAIRE automation does not transfer to OpenMetadata or DataHub, so suggestions, classifications and stewardship workflows that ran automatically will need manual rules, ingestion configuration and ownership assignments. Ask any partner to split the estimate into source connectors, lineage validation, glossary migration, data quality tests and access configuration so each part can be checked.
Can our team replace the catalog without outside help?
Yes, a capable platform team can deploy and run either tool, but the work is more than installation. OpenMetadata documents production deployments on Kubernetes (AWS EKS, Azure AKS, Google GKE and on-premises clusters) and on bare metal, and DataHub uses Helm charts plus a separate prerequisites chart. Teams without recent Kubernetes, Kafka or Elasticsearch experience often choose outside help for the first deployment, hardening and backups. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms in your own environment under a written, fixed scope, and it also offers retainers for ongoing upgrades and support.
How long does a catalog migration take for our source count?
Duration scales with the number of sources, the depth of lineage you need and the quality of your existing glossary. Sources with standard connectors, such as warehouses and BI tools, are faster to onboard than custom systems, and OpenMetadata lists more than 130 connectors while DataHub lists more than 150 integrations, so check that each of your sources is covered before planning. A written scope should give the timeline for each phase, and the timeline should be confirmed against your own environment rather than against a general estimate.
What does the work need from our internal staff?
Plan for data owners, stewards, platform engineers and a security reviewer. Data owners confirm which assets, glossary terms and classifications matter. Platform engineers run the deployment, database, search and message infrastructure. Stewards define data quality tests and ownership rules that CLAIRE used to suggest, and security staff review authentication and access. Ask any implementation partner to name the roles and the hours expected from each before work starts.
Should we choose OpenMetadata or DataHub for this catalog?
Both cover metadata discovery, lineage, glossary and data quality, so the choice rests on your operating model. OpenMetadata is Apache 2.0 licensed, documents bare metal deployment with Java 21, PostgreSQL or MySQL and Elasticsearch or OpenSearch, and offers Python, TypeScript and Java SDKs. DataHub is Apache 2.0 licensed and built around a metadata service with Kafka streaming and graph-based search, and it is deployed through Kubernetes Helm charts, so Kafka and graph operations become part of your run cost. Run a proof of concept against your top five sources and your hardest lineage path before deciding. Confirm current versions in each project's release notes, since OpenMetadata 2.0 includes breaking changes for ingestion images and embedding credentials.
How does SSO work on self-deployed DataHub Core compared with DataHub Cloud?
On self-deployed DataHub Core, the operator configures OpenID Connect on the frontend server, using a provider such as Google, Okta or Azure AD. DataHub Cloud enables OIDC SSO through its interface. Core therefore needs your identity team to create the client registration, set redirect URIs, and maintain the configuration through upgrades, which is a recurring task. Review the DataHub OIDC SSO guide with your identity team before deployment, and confirm how group claims map to DataHub roles in your environment.
Do we need DataHub Cloud or Collate's commercial offerings?
No, both projects are open source under Apache 2.0, so a self-hosted deployment does not require a commercial subscription to run the core catalog. DataHub Cloud is a managed, SLA-backed option with no infrastructure to run, and Collate sells commercial enterprise capabilities and premium support for OpenMetadata. Buy them only if you want managed operations or a support contract that your team cannot cover internally. Features that are restricted to commercial editions should be confirmed in each project's documentation before you finalize scope.
How DeployOpen scopes and delivers a catalog replacement
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 catalog replacement, that means a written scope covering which sources, lineage paths, glossary terms and quality checks move off Informatica, and which stay with the team.
How we scope
- Inventory the Informatica Data Catalog sources, resource types and CLAIRE-assisted stewardship tasks your teams actually use today.
- Agree in writing which connectors, lineage paths and glossary domains OpenMetadata or DataHub will cover, and which are excluded.
- Confirm the hosting target, Kubernetes or bare metal, along with database, search and Kafka choices before any build work starts.
How we build
- Deploy the chosen catalog with its metadata store, search index and ingestion runners inside your environment, sized to the documented prerequisites.
- Configure ingestion for each agreed source, then test lineage output and data quality tests against known tables and pipelines.
- Set up single sign-on through your OpenID Connect provider, including the frontend configuration that self-deployed DataHub Core requires from the operator.
How we hand over
- Deliver runbooks for ingestion schedules, upgrades, backups and the system update jobs that run during version changes.
- Document the stewardship workflow that replaces CLAIRE suggestions, including which metadata owners approve glossary and classification changes.
- Walk your platform and data teams through the admin console, APIs and the configuration keys they will maintain after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the initial build.
- Track maintenance releases for the chosen catalog and plan upgrades around breaking changes listed in the vendor release notes.
- Ask any quote to separate one-time build effort from recurring retainer work, infrastructure and any commercial vendor support you choose to add.
