Google Cloud Dataplex vs DataHub

The honest answer depends on your usage, so the first step is to ask Google for current pricing for the Dataplex Universal Catalog (Knowledge Catalog) features and billing dimensions that apply to your organization. Google bills these as consumption on Google Cloud, so the cost moves with the resources you catalog, the metadata you process and any related services you use. Do not compare a Google invoice line with a DataHub infrastructure estimate directly. Instead, model both sides across the same twelve months: your Google Cloud metadata usage today, the growth you expect, and the infrastructure, staff and migration costs listed in the other answers on this page. Ask your Google account team for the pricing terms in writing and keep the figures with your scope.

DataHub Core is licensed under the Apache License 2.0, so there is no licence fee to run the open-source edition. The license cost you do not pay is the one you should still verify in your own procurement process, because the company behind DataHub also sells DataHub Cloud, a separate commercial product. Confirm with your legal team that the Apache-2.0 terms fit how you plan to modify, bundle and distribute the software. Any subscription you choose later, such as DataHub Cloud, is a different line item and should be quoted separately.

Infrastructure is the main recurring cost of self-hosting DataHub. The DataHub Kubernetes guide describes four main components, GMS, the MAE Consumer, the MCE Consumer and the Frontend, which depend on Kafka, a MySQL, PostgreSQL or MariaDB database, Elasticsearch for search and a graph index on Neo4j or Elasticsearch. Costs rise with the number of sources, the volume of metadata, the frequency of ingestion and the redundancy you require for production. Your cloud provider or data center bills the compute, storage, network and managed services you choose. For a sizing estimate, ask your platform team to model the clusters and managed services in your own environment, and treat the minimum local test setup described in the documentation as a development baseline, not a production sizing.

Staff time is recurring and usually the largest cost after infrastructure, and it grows with the number of connectors and environments you run. The main activities are installation, upgrades, SSO configuration, monitoring the Kafka and search components, and maintaining ingestion recipes as source systems change. The DataHub Helm chart runs a system-update job on upgrades to apply schema changes and reindex search indices when needed, which reduces manual work but still needs a maintenance window and rollback planning. Configuring OIDC single sign-on on self-deployed DataHub Core is an operator task, so budget for it. Ask any implementation partner to itemize these tasks, the roles involved and the number of hours they expect for each, and to state who owns each task after handover.

A migration from Dataplex to DataHub is a one-time cost. It covers scoping which entries, glossaries and curated fields move, setting up BigQuery and Looker ingestion in DataHub, exporting metadata from Dataplex, mapping entry groups and glossary terms, and validating the result with the business owners. Costs rise with the number of sources outside Google Cloud, the amount of curated metadata that must be remapped, the number of access and policy rules to rebuild and the approval steps your governance program requires. Ask for a written scope with deliverables, assumptions, acceptance criteria and a list of what the client team must provide, such as access to source systems and named data owners. Most DeployOpen engagements are fixed-scope and agreed in writing before work starts.

DataHub Cloud is an optional subscription, and it replaces some of the infrastructure and operations costs above with a vendor-run service. According to DataHub's comparison documentation, it adds features not in open source, including data quality monitoring, AI anomaly detection, compliance forms, access request workflows, a 99.5% uptime SLA and AWS PrivateLink. Choose it only if those features or the SLA justify the subscription for your organization, and compare the quote with the infrastructure, staff and support costs of your self-hosted plan. Also check where your data would be processed, because a managed service changes the data residency picture. Ask the vendor for the subscription terms, the SLA definitions and the exact features included at your deployment size.

Request a quote that separates recurring and one-time costs and states its assumptions. Ask for the following:

• A list of the Google Cloud and other source systems in scope, with the expected metadata volume and ingestion frequency.
• The infrastructure design for Kubernetes, Kafka, the database and search, with the assumed sizes, redundancy and cloud pricing source.
• The staff effort for installation, upgrades, OIDC SSO setup and connector maintenance, with the roles and the handover plan.
• The migration deliverables, acceptance criteria and client responsibilities.
• Whether support, upgrades or continuous testing are included, or offered as a separate retainer.
• Any optional DataHub Cloud subscription, quoted separately.

DeployOpen does not publish a price list, and a quote follows from the written scope.

Yes, many teams run DataHub themselves if they have Kubernetes, data engineering and identity skills in house. The open-source edition is available under Apache-2.0, and the Docker quickstart is useful for evaluation, but production deployment on Kubernetes needs planning for Kafka, the database, search, backups and upgrades. The skills gap usually appears in SSO configuration, connector maintenance and security hardening. Assess your team against those tasks before deciding. If you want outside help, DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, under a written, fixed scope, with ongoing support available as a retainer.

DataHub Core has no license fee, so the cost is the infrastructure and the people who run it. The main drivers are the Kubernetes cluster that hosts GMS, the consumers and the frontend, the Kafka, relational database and search services it depends on, storage and backup for those services, and the engineering time for upgrades, monitoring and ingestion pipelines. Costs rise with the number of sources, metadata volume, search load and how many environments you keep (development, test, production). Dataplex is billed through Google Cloud, so compare its usage charges with your own infrastructure and staffing. When you ask for a quote, request a line-item breakdown of one-time setup, recurring infrastructure, recurring support, and what each assumes about source count and environments.

Duration depends on scope: how many sources you connect, whether you need single sign-on, how many environments you build, and how much glossary and ownership content must be loaded before the catalog is useful. A proof of concept on a single machine is much smaller than a production cluster with high availability, backups and integrated identity. DeployOpen agrees timelines in a written, fixed scope before work starts, so ask for the milestones, the assumptions behind them and what would move them. Your own readiness, such as cluster access and identity provider configuration, is often the largest variable.

Yes, if your team already operates Kubernetes and can support Kafka, a relational database and Elasticsearch or OpenSearch in production. The DataHub Kubernetes guide describes Helm charts from the acryldata/datahub-helm repository plus a separate prerequisites chart, and the upgrade process runs a system-update job that applies schema changes and reindexes search when needed. Teams without these skills usually need help with capacity planning, upgrade testing and incident response. Assess the gap honestly: list who will own each service, who is on call, and who has tested an upgrade in a non-production environment.

The work depends on access and decisions from your side. You will typically need a list of data sources with owners and connection methods, cloud and cluster access in your own accounts, identity provider details for OpenID Connect single sign-on, and network rules for connectors. For the business glossary and ownership model, you need named people who can approve term definitions and assign data owners, since the tool cannot decide those for you. Agree on who signs off on classifications and on which environment is the system of record before ingestion begins.

Only if you require a vendor-backed uptime commitment or private connectivity through AWS PrivateLink. DataHub's comparison documentation lists a 99.5% uptime SLA and AWS PrivateLink as DataHub Cloud features that are not in open source. DataHub Cloud also adds data quality monitoring, AI anomaly detection, compliance forms and access request workflows. If your organization needs these, factor the subscription into the cost comparison. If you can meet availability and network needs with your own cluster design and operating processes, DataHub Core under Apache-2.0 avoids that recurring fee. Confirm the current feature list directly with the vendor before deciding.

Yes. Knowledge Catalog (formerly Dataplex Universal Catalog) supports metadata export jobs that write JSONL files to Cloud Storage, which you can query with BigQuery and transform for another catalog. Choose the scope carefully: organization, project or entry group. Export gives you the metadata, but you still need to map entry groups, aspects and glossary terms to DataHub concepts and re-ingest technical metadata from sources such as BigQuery and Looker. Curated descriptions, owners and policy tags need explicit mapping, and BigQuery policy tags stay tied to Google Cloud IAM unless you redesign access. Ask for a mapping review as part of the migration scope.

Check the operational dependencies first: Kafka, search and the metadata database each need capacity, backups and monitoring, and a failure in one affects catalog availability. Verify the upgrade path in a staging environment, because the system-update job reindexes search when required. Confirm single sign-on setup on self-deployed DataHub Core, since the operator configures the frontend server. Finally, review whether the open-source feature set covers your governance workflows, particularly access requests and compliance forms, which are listed among DataHub Cloud features.