Which should a regulated team choose: Collibra or DataHub?
If your metadata must stay in your own infrastructure, DataHub is the open-source option to evaluate; if you want a vendor to run the catalog and your workflows already sit in Collibra, Collibra remains the lower-effort path. The decision usually starts with a renewal, a pricing change, a residency requirement, or the fact that commercial customers have had no maintained on-premises Collibra option since January 30, 2023. Collibra's position is that on-premises support continues for the public sector, so a regulated commercial team should confirm its current deployment options directly with Collibra before assuming any path is closed. Collibra fits teams that want a SaaS platform run by the vendor on AWS or Google Cloud, Edge sites for processing inside the network, and governance workflows the organization has already built and trained people on.
DataHub fits teams that must keep catalog and governance metadata inside their own data center or private cloud and can operate the stack that goes with it. Under the Apache-2.0 license, the self-hosted edition runs a metadata service (GMS), a Kafka stream for metadata changes, a MySQL or PostgreSQL database, Elasticsearch or OpenSearch for search and a graph index on Neo4j or Elasticsearch, deployed through the acryldata Helm charts. Before committing, ask your platform team whether it can run and patch those components, and confirm that the DataHub Kubernetes guide matches your cluster standards. Also confirm that you can configure OIDC single sign-on on the self-deployed frontend, since that is an operator task in DataHub Core, not a settings page.
The decision turns on three questions. First, hosting: if a regulator or policy requires that metadata never leave your environment, DataHub's self-hosted model meets that requirement directly, while a SaaS catalog needs contractual and technical review. Second, workflows: access request workflows, compliance forms and the observability features described for DataHub Cloud are not in the open-source edition, so list which of them your stewards rely on today and decide whether to build them or buy them. Third, operating capacity: you pay for infrastructure, staff time for upgrades and connectors, and the cost of recovering from failures, all recurring. Ask any vendor or partner for a written scope that separates one-time setup from ongoing operations, and compare both options on the same list of connectors and lineage sources.
Which scenarios favor Collibra and which favor DataHub
This table compares the scenarios where Collibra's managed platform fits best against those where self-hosted DataHub fits best. Read each row as a condition: if your situation matches the condition in the middle column, the option in the first column is usually the stronger starting point. DataHub Cloud is a separate paid product, not part of the open-source edition, so access workflows and compliance forms should be checked against the edition you plan to run.
| Scenario | Better fit | Condition that drives the choice |
|---|---|---|
| Data residency mandate | DataHub | Metadata must stay in your own cloud account or data center, and you can operate Kubernetes, Kafka, a SQL database and Elasticsearch yourself. |
| Public sector on-premises | Collibra or DataHub | Collibra says it continues to support on-premises environments for the public sector, so confirm current terms with Collibra; otherwise DataHub Core fits if you can host it. |
| Need for access request workflows and compliance forms | Collibra | These are not part of open-source DataHub. DataHub Cloud adds them as a separate paid product, so confirm whether a self-hosted build must include custom workflows. |
| Team with no platform engineering capacity | Collibra | A self-hosted DataHub deployment needs people to run Kubernetes, upgrades and dependencies. Without that capacity, a managed service is the simpler path. |
| Multi-cloud technical lineage | DataHub | DataHub lists column-level lineage and more than 150 integrations across warehouses and BI tools. Confirm connector coverage for your specific sources before committing. |
| Existing Collibra workflows and stewards | Collibra | Stewards who rely on Collibra's workflows, approvals and asset types will need retraining and rebuilt processes if you move. Plan a time-boxed review of workflows that do not transfer. |
| Budget that prefers license over staff time | Collibra | A subscription shifts operating work to the vendor. DataHub moves cost to infrastructure and engineering time, so ask for a quote that separates both before deciding. |
Where metadata lives and who operates it
The two products differ first on where the catalog runs and who patches it. Collibra is a vendor-run SaaS product with Edge sites for in-network processing, while DataHub Core is software your team deploys and operates. The cards below cover the decisions that follow from that split.
Collibra runs as SaaS
Collibra Platform is hosted by Collibra on AWS and Google Cloud, and Collibra operates the instance. Edge sites process data inside your network, so confirm with Collibra which metadata, sample values and lineage payloads leave your environment and which stay at the Edge. Ask for that answer in writing, per region and per deployment, before you rely on it for a residency requirement.
No maintained on-premises option
Collibra ended maintenance support for on-premises environments for commercial customers on January 30, 2023. It states it will continue to support on-premises environments for the public sector. If your Collibra instance is still on-premises as a commercial customer, plan the exit as a migration, not a patch cycle, and confirm your current support status with Collibra.
DataHub Core in your environment
DataHub's open-source edition is Apache-2.0 licensed and runs in your cloud account, data center or private network. Your team owns the Kubernetes cluster, Kafka, the relational database, search and the graph index, along with upgrades and backups. Because the metadata stays where you deploy it, the residency answer depends on your own network design rather than a vendor's region list.
OIDC configured by the operator
On self-deployed DataHub Core, the operator configures the frontend server for OpenID Connect single sign-on with providers such as Okta, Azure AD or Google. DataHub Cloud enables OIDC through its interface instead. Plan for certificate rotation, group-to-role mapping and the identity provider's logout behavior as ongoing operator work, and test them in staging before go-live.
Compliance evidence stays with you
Your team prepares the controls, configurations, access reviews and logs that a compliance assessment examines. Independent auditors and certification bodies review that evidence and issue any reports. DeployOpen prepares systems, controls and evidence for assessments but does not issue audit reports, attestations or certifications, so the evidence plan should be agreed with your auditor before the build starts.
Confirm data flows with each vendor
Before comparing costs, ask Collibra which Edge components, support access paths and backups touch your metadata, and ask the DataHub Cloud provider where its managed copies sit if you consider that tier. For DataHub Core, the question is which connectors send data to your own servers. Record each answer with its date, because the data flows are part of your risk assessment.
What running DataHub involves on Kubernetes
Running DataHub on Kubernetes is an operating commitment, not a single install. The DataHub Kubernetes guide describes four main components: the GMS (the metadata service), the MAE Consumer, the MCE Consumer and the Frontend. These depend on Kafka for streaming metadata changes, a relational database (MySQL, PostgreSQL or MariaDB), Elasticsearch for search and a graph index that runs on Neo4j or Elasticsearch. Each of these is a stateful system your team will patch, size, back up and monitor, and the catalog is only as available as the slowest of them. Before choosing between Neo4j and Elasticsearch for the graph index, confirm with the DataHub Kubernetes documentation which option matches your existing database and search skills.
The deployment is packaged as Helm charts from the acryldata/datahub-helm repository, with a separate prerequisites chart for the dependencies. Plan to manage two releases, pin chart versions, and keep your values files in version control so that upgrades are reviewed, not improvised. On upgrades, the chart runs a system-update job that applies schema changes and reindexes search indices when needed. Schedule upgrades in a maintenance window, test the job against a copy of production data, and confirm that your backup of the database and search indices can restore a working catalog before you start.
Two numbers in the documentation set the scale of the evaluation path. The guide says more than 7 GB of RAM is needed to run DataHub and its dependencies on Minikube, and the README says the Docker quickstart requires Docker with 8 GB of RAM and Python 3.10 or later. The quickstart is useful for a proof of concept on a laptop, but it is not a production topology. Use it to test connectors and the user interface, then size a multi-node cluster, separate environments for development and production, and set up authentication. The OIDC SSO guide notes that on self-deployed DataHub Core the operator must configure the frontend server, so budget that work explicitly.
What each option costs over time
Collibra's cost is a subscription plus Edge infrastructure, while a self-hosted DataHub moves the cost into infrastructure, integration and people that you own. Each card below names who gets paid, whether the cost is one-time or recurring, and what moves it up or down. No figures here are price estimates, so use the written quote and scope as the basis for any comparison.
Collibra subscription and Edge
Collibra is paid a recurring subscription for its SaaS platform, and Edge sites add infrastructure you run inside your network for processing. Collibra's on-premises maintenance ended for commercial customers on January 30, 2023, so the commercial path is SaaS. Ask Collibra for a written quote that itemizes the subscription, Edge components, support tier and renewal terms, and confirm which features are in scope.
DataHub software license
DataHub Core is Apache-2.0 licensed, so there is no license fee for the open-source edition. Cost sits in the features that DataHub Cloud adds, such as compliance forms, access request workflows and managed uptime, which are sold by the company behind DataHub. Check which of your required workflows are in Core before you budget, and request a written quote if you need Cloud features.
Kubernetes cluster
You pay for the cluster that runs the GMS, MAE and MCE consumers and the frontend, usually as cloud or data center compute. It is a recurring cost that grows with metadata volume, ingestion frequency and the number of environments, such as dev, test and production. Local evaluation has a lower bar: the DataHub Kubernetes guide says more than 7 GB of RAM is needed on Minikube, and the Docker quickstart requires 8 GB of RAM. These are minimum test figures, not production sizing.
Kafka, database, search and graph
DataHub needs Kafka for streaming metadata changes, a MySQL, PostgreSQL or MariaDB database, Elasticsearch for search, and a graph index on Neo4j or Elasticsearch. These are recurring infrastructure costs, either as managed cloud services or as systems your team operates, and they drive storage, backup and high-availability spend. Ask your platform team whether to use managed services, and scope backup and restore testing in writing.
Connector setup and maintenance
Connecting sources such as Snowflake, BigQuery, Databricks, dbt, Looker and Tableau is a one-time build effort followed by recurring maintenance when source APIs or permissions change. Collibra Edge sites are replaced by connectors that you configure and run. Count your source inventory, credentials handling and scheduling, and request in the scope which connectors are first-party DataHub and which need custom work.
Glossary migration and upgrades
Moving communities, domains, glossary terms and relations is a one-time project, and upgrades are recurring. The DataHub Helm chart runs a system-update job on upgrades to apply schema changes and reindex search when needed, so plan a test upgrade in a non-production cluster before each release. Scope the glossary mapping, the export format from Collibra and the upgrade calendar as separate line items.
Staff and operating model
Staff is the largest recurring cost in a self-hosted catalog and is often under-counted. Someone must own the cluster, the databases, ingestion schedules, SSO configuration and stewardship workflows that Collibra handles in its product. Compare the internal hours needed against the Collibra support tier, and decide whether to retain an implementation partner for setup and a retainer for upgrades and continuous support.
How a move from Collibra to DataHub proceeds
The sequence moves governance content and technical metadata out of Collibra into a self-hosted DataHub instance that your team operates, and it ends only after the new catalog has been checked against the old one. Scope, deliverables and the order of work are agreed in writing before any step starts, and no duration is assumed here.
Inventory assets, relations, domains and stewards
Start by listing what Collibra holds: data assets and their types, relations, domains, communities, business glossary terms, stewards and owners, and the data sources connected through Edge. Your team and the DeployOpen engineers record which items are authoritative, which are stale and which are used by reports or approval workflows. The output is a signed-off inventory that defines the migration scope, and the scope and deliverables are agreed in writing before work begins.
Export assets and relations from Collibra
Use Collibra's table-based export to CSV or XLSX for assets and complex relations. The export follows the filters, columns and sorting applied to the table on screen, so set those views deliberately before exporting and keep a record of each view. For scripted reads, the Core REST API can return the same content. Confirm the export format and row limits in your own Collibra version. The step is done when every exported file has been checked against record counts in the inventory.
Stand up DataHub in a test environment
Deploy DataHub Core in a non-production cluster using the Helm charts from the acryldata/datahub-helm repository and the separate prerequisites chart for Kafka, the relational database, Elasticsearch or OpenSearch and the graph index. Configure OIDC single sign-on yourself, because on self-deployed DataHub Core the frontend server is set up by the operator. The step is complete when the test instance starts cleanly, users can sign in through your identity provider, and the upgrade path has been tested once.
Map communities and domains to DataHub domains
Translate Collibra communities, domains and their hierarchies into DataHub domains and ownership assignments. Decide which Collibra structures become domains, which become owner groups and which are retired. Record each mapping in a table that the data owners sign off. The step is complete when every Collibra community and domain has a documented target, and the mapping has been reviewed by the people who approve governance content.
Convert glossary content to DataHub's YAML business glossary
Transform the glossary export into DataHub's YAML business glossary source, covering terms, definitions, term groups, owners and relationships between terms. Load the file into the test environment and check that terms resolve, that relations point to the right terms and that owners exist as users or groups in DataHub. Terms that depend on Collibra-specific attributes or workflow states need an explicit decision. The step is done when a glossary reviewer confirms the sample terms match their Collibra originals.
Re-ingest technical metadata and lineage
Configure DataHub ingestion recipes for each source in scope, such as Snowflake, BigQuery, Databricks, dbt, Looker or Tableau, and run them against the test instance. Connect Collibra's Edge-managed sources through DataHub's own connectors and credentials, which your team stores and rotates. Confirm column-level lineage where the connector supports it, and list any source that needs a new connector or a custom build. The step is complete when each source produces its expected asset count and lineage edges.
Rebuild lineage and stewardship workflows
Identify the Collibra workflows that have no direct DataHub equivalent, such as custom approval chains, attribute-level stewardship tasks and some compliance forms, and decide how each will work. DataHub Cloud provides compliance forms and access request workflows, but these are not part of the open-source edition, so an open-source design needs a separate process or custom work. Document each replacement workflow and who operates it. The step is done when every retired Collibra workflow has a documented replacement or an approved decision to drop it.
Run parallel validation and cut over
Run Collibra and DataHub side by side for a period agreed in the written scope. Compare asset counts, glossary terms, lineage paths and ownership against the inventory, and have stewards check a sample of records in each domain. Once discrepancies are resolved and sign-off is recorded, switch users and integrations to DataHub, then decommission Edge agents and revoke their credentials. Keep the final Collibra export archived under your retention policy. The step closes when the cutover record, the retired-agent list and the archived export are stored together.
Questions buyers ask before choosing DataHub
How much does a self-hosted DataHub cost compared with Collibra?
No single figure can be given fairly, because the answer depends on your own environment and scope. DataHub Core is Apache-2.0 licensed, so there is no license fee for the software itself. Your costs are the Kubernetes cluster, the Kafka, Elasticsearch or OpenSearch, database and graph index infrastructure, connector setup, the people who run the platform, and any external help. Collibra's cost is a subscription that covers the platform and, if you use it, Edge infrastructure. Ask any quote to split one-time work (deployment, connector build, glossary load) from recurring work (hosting, upgrades, on-call operations). Ask the vendor for a written subscription quote covering the same scope, and compare it with your own infrastructure and staffing estimate for the same number of sources and users.
How long does a migration from Collibra to DataHub take?
The timeline is set by scope, not by the tool. The main drivers are the number of technical sources to re-ingest, how many business glossary terms and domains need to be mapped, how much Collibra workflow logic has to be rebuilt, and how much of your lineage depends on Collibra-specific integrations. Each source needs a DataHub connector configured and tested, and each glossary export needs conversion into DataHub's YAML business glossary source. Ask for a written plan with phases, acceptance criteria per source and a list of Collibra workflows that have no direct equivalent. Any duration in a proposal should be tied to that inventory, and you should ask what changes if the inventory grows.
What does the work need from our team?
Expect to supply several roles. Platform engineers own the Kubernetes environment, the Helm deployment and the Kafka, database and search dependencies. Data engineers own connector credentials, ingestion schedules and lineage sources. Data stewards own the glossary, ownership and domain decisions, which no tool can make for you. Security staff own SSO, role mapping and access review. Ask any implementation partner to list which of these roles it covers and which it expects you to fill. Also confirm who holds the Helm values, secrets and runbooks after handover, so the platform does not depend on one person.
Can we do the DataHub migration ourselves?
Yes, if your team has Kubernetes and data platform experience and the time to learn DataHub's architecture. The DataHub Kubernetes documentation describes Helm charts from the acryldata/datahub-helm repository plus a separate prerequisites chart, so a capable platform team can start from there. The harder parts are usually connector configuration across many sources, glossary conversion, governance decisions and handover of operations. Many teams run a pilot with a small set of sources first, then decide which work to keep in-house and which to scope out to an outside partner. DeployOpen works on fixed-scope engagements agreed in writing, and ongoing support and upgrades are available as retainers.
Does DataHub support SSO with Okta or Azure AD?
DataHub supports single sign-on through OpenID Connect providers, and its OIDC SSO guide names Google, Okta and Azure AD as examples. On self-deployed DataHub Core, your operator must configure the frontend server for OIDC, including the client registration with your identity provider and the callback settings. DataHub Cloud enables OIDC SSO through its interface instead. Ask your identity team to confirm the claims you need for role mapping, how group membership maps to DataHub roles, and how deprovisioning works when someone leaves. Test sign-in and role assignment in a non-production environment before cutover.
Do we need DataHub Cloud for access workflows and compliance forms?
Based on DataHub's comparison documentation, access request workflows and compliance forms are among the features that DataHub Cloud adds beyond open source, along with data quality monitoring, AI anomaly detection, a 99.5% uptime SLA and AWS PrivateLink. Open-source DataHub includes governance features such as ownership, domains, glossary and data quality assertions, but you should not assume it covers Collibra's access approval or form-based attestation flows. Map each Collibra workflow you use today to a DataHub feature or to a process you will run outside the tool. Confirm the current feature split with the vendor before you commit, because the boundary between editions can change.
What happens to DataHub during upgrades?
The DataHub Helm chart runs a system-update job on upgrades to apply schema changes and to reindex search indices when needed. That job is part of the upgrade path, so plan for downtime or degraded search during reindexing, and test the job against a copy of your data first. Read the release notes for each version before upgrading, since the project publishes frequent releases. Keep Kafka, the database and Elasticsearch or OpenSearch within the versions the release supports, and take backups of the database and search indices before each change. Ask any partner for a written upgrade runbook, a rollback plan and a schedule that fits your change windows.
When should we stay on Collibra instead of moving to DataHub?
Stay on Collibra if the cost of rebuilding its workflows outweighs the benefit of self-hosting, or if your governance model depends on Collibra features you cannot map to DataHub. Also consider Collibra if your team cannot staff the Kubernetes, Kafka and search operations that a self-hosted catalog requires. Moving is the stronger case when data residency, licensing terms or lock-in are the main concerns. If your organization is on the public sector on-premises path, check the vendor's current support statements, since Collibra has said it will continue to support on-premises environments for the public sector while ending maintenance for commercial customers on January 30, 2023. Make the decision from a written inventory of your Collibra usage, not from a general preference.
Where DataHub Core falls short and how to close the gap
The main gap between DataHub Core and the commercial product is that access request workflows, compliance forms, AI-assisted data quality monitoring, AWS PrivateLink and a 99.5% uptime SLA are documented as DataHub Cloud features, not open-source features. Before you decide, check each of these against the current DataHub comparison documentation, because the split between Core and Cloud can change between releases. Treat the Cloud feature list as the starting point for your gap analysis, not as a fixed fact about the open-source edition.
Collibra customers often rely on built-in approval routes for data access, attestation or policy sign-off, and on forms that capture regulatory or privacy attributes on each asset. On DataHub Core, plan for these to be built or run as process. Options include an external ticketing or approval tool that writes ownership and tag changes back to DataHub through its APIs, and a documented steward review step in your change calendar. Confirm which of your Collibra workflows are actually automated today, since many teams find that some are run by email or spreadsheet, and those transfer without new build work.
On the operations side, Core means your team owns the data quality and availability story. Collibra's SaaS model hands uptime and upgrades to the vendor, while on Core you need monitoring for the Kubernetes deployment, Kafka, the database, search and the graph index, plus a tested upgrade runbook for the system-update job in the Helm chart. Decide early who is on call for the catalog, whether you will buy DataHub Cloud, a support contract or a DeployOpen retainer for upgrades and testing, and what availability your data consumers expect. Ask any vendor for written scope, responsibilities and remedies before you rely on them.
How DeployOpen helps evaluate, implement or migrate
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Collibra vs DataHub decision, we start with a written scope that fixes what is evaluated, built and handed over before any work begins.
How we scope
- Inventory which Collibra assets, relations, glossaries and Edge-connected sources your teams depend on today.
- Map each capability to DataHub Core or DataHub Cloud, and record which gaps your team must accept or fill.
- Agree the written scope, deliverables and timeline in writing, since most engagements are fixed-scope and quoted from that scope.
How we build
- Deploy DataHub on Kubernetes with Helm inside your environment, including Kafka, the database, Elasticsearch and the graph index.
- Configure OIDC single sign-on against your identity provider and document the frontend settings your operators must maintain.
- Test ingestion, column-level lineage, glossary imports and assertions against a representative sample before any production cutover.
How we hand over
- Deliver architecture, runbooks for upgrades and the system-update job, backup procedures and access control documentation.
- Provide controls and evidence packs that your internal teams or independent auditors can review; DeployOpen does not issue audit reports or certifications.
- Train the operators who will own the catalog, and confirm with them which responsibilities stay in-house after handover.
How we support
- Offer ongoing support, upgrades and continuous security testing as retainers after the fixed-scope work closes.
- Plan each DataHub version upgrade in a staging environment, reviewing release notes before changing production.
- Ask us in the scoping call to confirm which support tier, testing cadence and response expectations fit your governance program.
