DataHub Cloud vs self-hosted DataHub

The Cloud-only features named for this comparison are AI documentation, observability monitors, access request workflows, compliance forms and a service level agreement (SLA). The supplied facts describe DataHub Cloud as managed and SLA-backed, but they do not list the feature-by-feature split between DataHub Cloud and open-source DataHub Core. Treat the list above as the vendor's current claim, not a settled fact, and ask the vendor in writing which of these capabilities are absent from Core, which ship only in a specific Cloud tier and whether any of them will reach Core later. A team that stays on Core should assume it must build or source equivalents for each item it needs, and should write that assumption into its plan.

For a team that stays on Core, the practical consequences differ by feature. AI documentation, if it is a Cloud feature, means descriptions for tables and columns are written by hand or by a process the team builds itself, which adds stewardship work that recurs with every schema change. Observability monitors and data quality assertions affect the platform design: the README lists assertions and monitoring among DataHub's features, so the team must confirm exactly which monitoring behaviors Core covers before assuming a gap. Access request workflows and compliance forms would require either a custom approval process outside DataHub or a Cloud subscription. The SLA is the least visible item and the most consequential for regulated teams: with Core, the team carries the uptime commitment for the Kafka, database, search and graph services it runs itself, and the SLA question should be answered by the team's own operating model rather than by a vendor document.

The main difference is who configures the OIDC connection. DataHub supports single sign-on through OpenID Connect providers such as Google, Okta and Azure AD. On self-deployed DataHub Core, the operator must configure the frontend server to talk to the identity provider, which means the platform team owns the settings, the secret handling and every change that follows an upgrade. With DataHub Cloud, OIDC SSO is enabled through the product interface, so the work moves from editing deployment configuration to completing a guided setup with the vendor's support.

In both models, the identity team has to supply the same core inputs. They register DataHub as an application with the identity provider, define the redirect URI that the DataHub frontend will call back to after login, issue a client ID and client secret, and decide which claims or groups carry the user's role. On Core, those values end up in the Helm values and Kubernetes secrets for the frontend, so the secret rotation process and the namespace where the secret lives must be designed before go-live. On Cloud, the same values are entered in the interface, and the identity team should confirm who holds admin rights to change them later.

Group mapping deserves its own review before either option is chosen. Confirm which groups in your directory should map to DataHub roles, who approves changes to that mapping, and how a user removed from a directory group loses access. Treat the exact field names, redirect URI format and claim handling as items to verify against the DataHub OIDC SSO configuration guide for your version, since those steps differ by release and by deployment. Ask the vendor to walk through the Cloud setup on a test tenant before committing to the model.

Settle where metadata is allowed to live before any feature comparison. Self-hosted DataHub Core runs in your own cloud account or data center, which means your team owns the GMS service, Kafka, the MySQL or PostgreSQL store, the search index and the graph index, and every network path between them and your source systems. DataHub Cloud moves operation of that stack to the vendor, so the question for security and compliance leads is whether catalog metadata (schema names, lineage, ownership, and any sample or profiling data pulled from sources) may leave your boundary and under which contract. Ask the vendor to document exactly what is transmitted during ingestion, what is stored outside your network, and where it is hosted. Confirm with your own data protection and legal teams whether that answer is acceptable for each source system before you sign.

Decide which Cloud-only features are genuinely required, and who needs them, before you price the platform. Access request workflows, observability monitors, AI documentation and compliance forms are the areas where Cloud differs from Core, and each has a different owner: an access request workflow matters to identity and access reviewers, monitors to data engineering, and compliance forms to the governance lead. If none of these is a stated requirement with a named owner, self-hosted Core may already meet the need, and you can revisit the question later. Write the requirement down as a user story with an acceptance test, then ask the vendor to show that feature working against a system you actually run. Also confirm the SLA terms in writing, since an SLA is only useful if its scope matches your critical data flows.

Assess your team's skills honestly, because the self-hosted path is a Kubernetes and data-store commitment. The DataHub Helm guide expects you to operate the main charts alongside a separate prerequisites chart for Kafka, the relational database, search and graph services, and the system-update job runs schema changes and search reindexing on each upgrade. Check whether your platform team can run Kafka, PostgreSQL or MySQL, and OpenSearch or Elasticsearch with backups, patching and capacity planning, and who is on call when ingestion stalls. Also ask who will own SSO on Core, since the OIDC frontend must be configured by the operator, and who owns quarterly access reviews. The budget owner should approve recurring operations (infrastructure, on-call time, upgrade windows and any retainer) as a line item, not as a one-time project cost.