Atlan or DataHub: when each option fits the decision
If your renewal, a data residency rule or a lock-in concern has put Atlan on the table next to DataHub, the first split is where the catalog runs. Atlan fits teams that want a vendor-hosted, single-tenant service, with only the Self-Deployed Runtime on site to reach on-premises or VPC-locked sources. DataHub fits teams that must keep the whole catalog, including its metadata service, search and storage, inside their own Kubernetes. Data location decides most of the comparison, so start there and settle it with your security and legal teams before you look at features.
The second filter is the feature list. Core catalog work such as connector coverage, column-level lineage, a business glossary and domains is available in open-source DataHub, so confirm those against your sources and your existing dbt, warehouse and BI estate. Some items your team may ask for are DataHub Cloud features that open source lacks, including compliance forms and access request workflows. If compliance forms or access requests are required from day one, price them as a managed-service decision rather than assuming the Apache-2.0 edition covers them. Ask Atlan which of your required features depend on the Self-Deployed Runtime and which run in its hosted service.
The third filter is who will operate the platform. A self-hosted DataHub deployment needs Kubernetes, Kafka, a relational database, Elasticsearch or OpenSearch and a graph index, and the Helm charts need ongoing upgrades and reindexing. The DataHub Kubernetes guide notes that more than 7 GB of RAM is needed for a Minikube test, which is a starting point for planning, not production sizing. If your platform team has no capacity for that, Atlan's hosted model shifts operations to the vendor, while a self-hosted choice moves those costs to your own staff and infrastructure.
Which scenarios favor Atlan and which favor DataHub
This table compares common buyer scenarios and names the platform that fits better and the condition that decides it. Read each row against your own constraints, since the right answer usually depends on where metadata may live and who will operate the catalog. DataHub Cloud is a separate managed product from the company behind DataHub, so the open-source edition is the option that runs on your own cluster.
| Scenario | Better fit | Condition that makes it so |
|---|---|---|
| Strict metadata residency | DataHub (open source) | Metadata, lineage and logs must stay inside your own network, since Atlan runs its platform as hosted SaaS and only the Self-Deployed Runtime sits on your side |
| Small platform team with no Kubernetes practice | Atlan | You want the vendor to host, upgrade and operate the platform and you can accept SaaS hosting for catalog metadata |
| Heavy reliance on Snowflake, BigQuery, dbt and Tableau connectors | Either, after a connector check | Confirm each source and version against the DataHub connector list and Atlan's connector catalog, since DataHub lists 150+ integrations |
| Need for compliance forms and access request workflows | Atlan or DataHub Cloud | Open-source DataHub does not include these features; confirm whether Atlan's current plan covers the workflows you need |
| Existing Kubernetes practice and platform engineers | DataHub (open source) | Your team can run Kafka, a relational database, Elasticsearch and the Helm charts, and has capacity for upgrades |
| Preference for a vendor SLA | Atlan or DataHub Cloud | Open-source DataHub has no vendor SLA; you would own uptime, backups and incident response yourself |
| Column-level lineage across pipelines | Confirm for both | DataHub's README lists column-level lineage; verify coverage for your specific sources in a proof of concept |
| Air-gapped or on-premises network | DataHub (open source) | Atlan requires SaaS hosting outside your network, while DataHub can be deployed entirely inside your environment |
Where metadata lives and who controls the runtime
Where your metadata sits, who operates the runtime and how users sign in decide most of the compliance and operations work in this comparison. The cards below set out how Atlan and DataHub differ on those points and what to confirm before you commit.
Atlan's single-tenant SaaS footprint
Atlan is a cloud-first, single-tenant SaaS platform hosted by Atlan on AWS, Azure or Google Cloud. Your catalog tenant lives in Atlan's hosting environment, and the only component you can run in your own network is the Self-Deployed Runtime, which reaches on-premises or VPC-locked sources. Ask Atlan which region hosts your tenant, where backups are kept and which data leaves your network through the Runtime. Metadata stored in Atlan's tenant is outside your direct operational control.
Self-Deployed Runtime scope
The Self-Deployed Runtime is the one Atlan component that executes inside your network. It handles connector work for sources that cannot be reached from the cloud, so your team patches and monitors that host while Atlan operates the rest. Confirm which connectors require the Runtime, which credentials it stores and how its outbound traffic is restricted. Map each source to either the Runtime or to Atlan's hosted connection path before you size the on-premises footprint.
Atlan's stated storage and identity stack
Atlan's architecture documentation says the platform is built on Apache Atlas for metadata storage, with Cassandra and Elasticsearch behind it, and uses Keycloak for SSO, OIDC and SAML. Because these components are part of a vendor-run service, you cannot inspect or tune them directly. Request Atlan's current data-flow diagram and its SSO configuration options so your identity team can confirm group mapping and session behavior before rollout.
DataHub's self-hosted metadata path
In a self-hosted DataHub deployment, the metadata service (GMS) receives changes through Kafka, stores records in MySQL or PostgreSQL and indexes them in Elasticsearch or OpenSearch. Every one of those stores sits in your Kubernetes cluster and your storage accounts, so backup, retention and encryption decisions are yours. Plan Kafka capacity, database backups and search index recovery as part of the operating model, and confirm how each component is encrypted at rest and in transit.
DataHub Core versus DataHub Cloud sign-in
On self-deployed DataHub Core, your operators configure the frontend server for OpenID Connect single sign-on with providers such as Google, Okta or Azure AD. DataHub Cloud enables OIDC SSO through its interface instead. Core therefore adds configuration and secret-handling work to your platform team, while Cloud moves that setup into the vendor console. Check who owns client secrets, token lifetimes and offboarding in each case.
Compliance evidence and auditor roles
Moving metadata into your own infrastructure changes which controls you must evidence, including access logging, change management for the catalog and backup testing. DeployOpen can help plan and prepare those controls and the evidence that supports them, but it does not issue audit reports or certifications. Independent auditors and certification bodies make those determinations. Ask your assessor early which of the controls Atlan's SaaS attestations currently cover and which would fall to your team after migration.
How the capabilities compare, feature by feature
This table compares Atlan's single-tenant SaaS with the Apache-2.0 DataHub edition you run yourself, row by row. Where a cell says DataHub Cloud only, that capability is not part of the open-source project and needs a separate commercial decision. Confirm every Atlan-side detail against Atlan's current documentation before you rely on it.
| Capability | Atlan | DataHub (open source) |
|---|---|---|
| Hosting model | Single-tenant SaaS hosted by Atlan on AWS, Azure or Google Cloud; only the Self-Deployed Runtime runs in your network | Runs entirely on your Kubernetes or Docker environment, inside your own network or air-gapped site |
| Licensing | Commercial subscription; confirm contract terms and what the Self-Deployed Runtime license covers | Apache License 2.0 for the open-source edition; DataHub Cloud is a separate commercial product |
| Connector coverage | Confirm the supported connector list against Atlan's current connector documentation | More than 150 integrations, including Snowflake, BigQuery, Databricks, dbt, Looker and Tableau |
| Column-level lineage | Supported; confirm which sources and transformations are covered for your stack | Included in the open-source README feature list |
| Business glossary and domains | Supported; glossaries and domains are part of the core product, confirm export formats | Business glossary included in open source; domains available, confirm the YAML and UI workflow for your version |
| SDKs and APIs | Python SDK (pyatlan) and Java SDK; confirm the API surface for your use case | Own SDKs and APIs; confirm language support and endpoints for your DataHub version |
| Data quality monitoring | Confirm feature scope and whether it is included in your plan | Data quality assertions and monitoring are listed in open source; AI anomaly detection is DataHub Cloud only |
| Compliance forms | Confirm availability in your plan | DataHub Cloud only, not in open source |
| Access request workflows | Confirm availability and approval flow in your plan | DataHub Cloud only, not in open source |
| Uptime SLA | Set by your Atlan contract; ask for the written SLA | No SLA in open source; the 99.5% uptime SLA applies to DataHub Cloud only |
| PrivateLink connectivity | Confirm whether AWS PrivateLink is offered for your tenant and region | DataHub Cloud only; self-hosted DataHub uses your own network controls |
Which features DataHub open source lacks and what to do about them
Compliance forms, access request workflows, AI anomaly detection, managed data quality monitoring and the 99.5% uptime SLA are DataHub Cloud features, not part of the Apache-2.0 open-source edition, according to the DataHub comparison documentation. If you adopt DataHub Core, you get the metadata service, ingestion, column-level lineage, the business glossary, and data quality assertions, but you build or operate the rest yourself. Treat each item below as a decision with a condition under which it starts to matter, not as a general shortfall.
The gaps matter in specific situations. Compliance forms and access request workflows matter when an auditor asks for evidence that a data owner approved a classification, a glossary change or a grant of access, and that the approval is recorded. The uptime SLA matters when analysts depend on the catalog during business hours and nobody on your team carries a 24/7 on-call rota to restore the search index or frontend after an outage. Managed data quality monitoring and AI anomaly detection matter when you lack the people to write and tune assertions for many tables. Ask your auditors which evidence they expect before you assume a workflow is optional.
For each gap, you have three realistic paths. First, build the workflow on the DataHub APIs and record approvals in a ticketing or case tool your auditors already accept, then link the ticket to the dataset. Second, add open-source tooling for a narrow need, such as an approval service in front of your own change process. Third, buy the managed DataHub Cloud product for the workflows and SLA. Atlan's built-in workflow and approval features should be confirmed in Atlan's own documentation and tested against your audit scenarios before you compare them with a self-built process. Whichever path you pick, write the decision and its owner into the migration plan.
What a catalog costs beyond the subscription line
An Atlan subscription is only one line in the budget. Running DataHub yourself moves the spend into infrastructure, people and upgrades, and some of those costs are one-time while others recur every year.
Atlan subscription and runtime hosting
Atlan charges a subscription for its single-tenant SaaS, and you pay separately for any compute, networking and staff needed to run the Self-Deployed Runtime in your own network for on-premises or VPC-locked sources. Ask Atlan for its own pricing in writing, including how the subscription is scaled and whether the Self-Deployed Runtime is priced separately. The recurring cost is the subscription plus the runtime's hosting. Confirm which connectors require the runtime, because that set determines how much infrastructure you keep.
Infrastructure for the DataHub stack
Self-hosted DataHub needs Kubernetes, Kafka, a MySQL, PostgreSQL or MariaDB database, and Elasticsearch or OpenSearch for search, plus a graph index on Neo4j or Elasticsearch. The Kubernetes guide says more than 7 GB of RAM is needed to run DataHub and its dependencies on Minikube, and the Docker quickstart requires 8 GB. Production sizing is recurring and grows with metadata volume and the number of connectors. Ask your platform team to price cloud or on-premises capacity for each tier before comparing with the subscription.
Implementation and connector setup
Initial work includes standing up the Helm releases from the acryldata/datahub-helm repository and its separate prerequisites chart, configuring each source connector, and mapping ownership, domains and glossary terms. This is mostly one-time effort, but every new source adds connector configuration and testing. Atlan's Self-Deployed Runtime connectors carry over as work to replace, so budget for a parallel run before cutover.
Upgrades and the system-update job
Each DataHub Helm upgrade runs a system-update job that applies schema changes and reindexes search when needed. That job touches the same database and search tier that serves production traffic, so upgrades need a maintenance window, a backup of the metadata store, and a rollback plan. Upgrades are a recurring cost that scales with how often you track releases. Plan for the platform team to test each release in a staging cluster before production, since version numbers move quickly.
SSO configuration on self-deployed DataHub
DataHub supports OpenID Connect providers such as Google, Okta and Azure AD. On self-deployed DataHub Core, the frontend server must be configured by your operators, whereas DataHub Cloud enables OIDC SSO through its interface. Setup is one-time, but certificate rotation, identity provider changes and access reviews recur. Confirm that your identity team can own the OIDC client configuration before you commit to the open-source route.
People who operate the catalog
With Atlan, the vendor runs the SaaS platform and your team mainly administers metadata and connectors. With self-hosted DataHub, an engineer or platform team owns Kubernetes, the data stores, backups, monitoring, security patching and on-call response. Staffing is the largest recurring cost and the hardest to predict. Estimate the share of an existing team that will carry this work, and ask any implementation partner for a written scope that names who supports the platform after handover.
How much operating effort each model asks from your team
A small data team without a Kubernetes practice usually finds that self-hosted DataHub asks for skills it does not have in-house. DataHub's Kubernetes guide describes four main components (GMS, the MAE Consumer, the MCE Consumer and the Frontend) that depend on Kafka, a relational database, Elasticsearch and a graph index, so someone must own that stack day to day. With Atlan, the team keeps the connector runtime and source access work, while the vendor runs the platform itself.
- Cluster upkeep: under DataHub, the team patches nodes, manages Helm releases from the acryldata/datahub-helm repository and watches resource use, which the guide says needs more than 7 GB of RAM even for a small Minikube test.
- Dependency upgrades: the team tracks Kafka, the database and search versions alongside each DataHub release.
- Search reindexing: the Helm system-update job handles schema changes and reindexing on upgrade, but the team must check that it completes.
- Connector scheduling and backups: under DataHub, the team schedules ingestion and backs up the metadata stores. Under Atlan, it manages only the Self-Deployed Runtime where needed.
- SSO: under self-hosted DataHub, the operator configures the OIDC frontend settings. Under Atlan, the team coordinates SSO with the vendor.
This model works when at least one engineer can operate Kubernetes and Kafka on a recurring schedule. Confirm that skill set before choosing DataHub, and ask the vendor or DeployOpen for a written operating plan that names who handles on-call responsibilities.
A platform team that already runs Kubernetes and Kafka can absorb most of DataHub's components into existing practice. The extra work is application-specific: DataHub's metadata service, consumers and search indices need their own capacity planning, monitoring and upgrade windows. Under Atlan, this team's effort shifts toward connector runtime placement and coordinating changes with the vendor, since the platform itself is hosted by Atlan.
- Cluster upkeep: the team adds DataHub namespaces, resource limits and dashboards to its current clusters rather than building a new operating model.
- Dependency upgrades: Kafka and search are already on the team's upgrade calendar, so DataHub's chart versions become one more item to test.
- Search reindexing: the team plans reindex runs and disk headroom, because the Elasticsearch or OpenSearch index is in the path of every upgrade.
- Connector scheduling: ingestion jobs run on the team's existing scheduler, and the team owns credentials and source network paths for each of the 150+ integrations listed in the README.
- Change coordination: under Atlan, the team agrees on maintenance windows and self-deployed runtime upgrades with the vendor, which becomes a recurring task.
This model works when the platform team already has Kafka and search in production and has a clear owner for the catalog. Confirm the Kubernetes version, Kafka operating experience and on-call coverage before committing.
A regulated team with a strict residency rule must keep metadata inside its own network, which narrows the choice. Atlan describes itself as a cloud-first, single-tenant SaaS hosted on AWS, Azure or Google Cloud, with only a Self-Deployed Runtime running in the customer's network. If the residency rule covers the metadata store itself, the team must confirm with Atlan where that data is held. Self-hosted DataHub keeps the full stack in the team's own Kubernetes environment, but the team then owns every control that follows from that.
- Cluster and access controls: the team documents network policies, encryption, and who can reach the GMS and the database, and ties those to its control inventory.
- Dependency upgrades: each DataHub, Kafka and database upgrade needs a change record and validation in a non-production environment before rollout.
- Backups and recovery: the team tests restores of the metadata database and search indices, not just backup jobs.
- SSO: OIDC settings on self-deployed DataHub must be configured and reviewed by the operator, with evidence kept for access reviews.
- Vendor change control: under Atlan, the team reviews vendor release changes against its residency and change policies.
This model works when the team can produce evidence for each operational control and has a documented owner for every component. Confirm with compliance which obligations apply to metadata itself, and ask your auditor which evidence they expect.
What moving from Atlan to DataHub involves at a high level
This sequence turns an Atlan estate into a self-hosted DataHub deployment with curated glossary, domains, ownership and lineage re-established, and teams cut over with their sign-in and connectors in place.
Inventory the Atlan metadata the business relies on
Work with data owners and catalog administrators to list the assets, glossary terms, domains, owners and tags that analysts and stewards use day to day, and separate them from metadata that connectors regenerate on every run. Name a business owner for each domain. The step is done when the list is signed off and every source system is tied to a named owner who will confirm the cutover later.
Decide what to export with the pyatlan SDK
Atlan documents its Python and Java SDKs rather than a published OpenAPI specification, so plan extraction around pyatlan. Your data engineers script exports of glossaries, descriptions, owners and tags, and confirm the SDK version and API access your Atlan tenant permits. Ask Atlan which export paths are supported for your plan. The step is done when each exported set has a documented schema and a test extract has been reviewed by the people who own it.
Stand up DataHub on Kubernetes in a non-production environment
Platform engineers deploy DataHub with the acryldata/datahub-helm charts and the separate prerequisites chart, which provision the dependencies DataHub needs, including Kafka, a relational database, Elasticsearch or OpenSearch and a graph index. Size the cluster from the DataHub Kubernetes guide, which states that more than 7 GB of RAM is needed for a Minikube trial, and confirm production sizing with the DataHub project and your own load. The step is done when the frontend loads, sample metadata is ingested, and the operator has rehearsed an upgrade through the system-update job.
Map Atlan domains and glossary to DataHub
Translate Atlan domains and glossary terms into DataHub domains and a business glossary written in DataHub's YAML format. Decide how each Atlan term maps to a glossary node, how term ownership transfers, and which custom metadata has no equivalent and needs a decision. Stewards review the mapping against the inventory from the first step. The step is done when every exported term and domain has a documented target, and the stewards have approved the exceptions in writing.
Re-ingest sources and validate lineage
Configure DataHub's connectors for each source system, such as the warehouses, transformation tools and BI platforms you use today, and run push or pull ingestion into the new instance. Compare asset counts, owners and column-level lineage against Atlan for a sample of critical tables and dashboards. Where a connector differs from Atlan's coverage, record the gap and the workaround. The step is done when the validation checklist for each source is complete and the lineage differences are logged for the business owners to accept or fix.
Cut over teams, SSO and Self-Deployed Runtime connectors
Configure OIDC single sign-on for DataHub, which your operator must set up on self-deployed DataHub Core, and grant access by group. Move each team in stages, and retire the Atlan Self-Deployed Runtime connectors once their sources are running under DataHub ingestion. Confirm the Atlan contract terms for data retention and exit with your procurement and legal teams before shutting down the tenant. The step is done when every team has signed in to DataHub, the runtime connectors are switched off, and an export archive is stored under your own controls.
Questions buyers ask before choosing or hiring help
How much effort and time does a DataHub deployment take?
The effort depends mostly on how many sources you connect, how much metadata you curate, and whether you run DataHub on a shared Kubernetes cluster or a dedicated one. The DataHub Kubernetes 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. A production cluster needs more headroom than either figure. The main components are GMS, the MAE Consumer, the MCE Consumer and the Frontend, plus Kafka, a relational database, Elasticsearch or OpenSearch, and a graph index. Each dependency adds operating work. Ask any provider for a written breakdown of connector count, environments, SSO setup and cutover tasks before you accept a timeline.
Can our team run DataHub without outside help?
A capable platform team can run DataHub without outside help, but it needs Kubernetes operations skills, Helm chart experience, and familiarity with Kafka, a relational database and a search engine. The Helm chart runs a system-update job on upgrades to apply schema changes and reindex search indices when needed, so upgrades need planning and a tested rollback path. Ingestion recipes for each source also need owners who understand the source systems. Your team also needs to configure OIDC on the self-deployed frontend yourself, while DataHub Cloud handles this through its interface. Decide who will own upgrades, on-call response and connector maintenance before you start.
What does our staff need to contribute to the project?
Your staff must supply the business context that no tool can infer. That includes the owners of each data domain, the people who can approve the business glossary terms, the security team that defines classification rules, and the engineers who can grant read access to source systems for ingestion. Someone must also provide a Kubernetes environment, network paths to each source, and an identity provider application for SSO. Expect the largest share of effort to fall on glossary and ownership decisions rather than on installation. Confirm these commitments in writing with any implementation partner so that data owners and reviewers are scheduled before work starts.
Does open-source DataHub include compliance forms and access request workflows?
No. Compliance forms and access request workflows are features of DataHub Cloud, the managed product from the company behind DataHub, and they are not part of the Apache-2.0 open-source edition. DataHub Cloud also adds data quality monitoring, AI anomaly detection, a 99.5% uptime SLA and AWS PrivateLink, according to the DataHub comparison documentation. If you need these workflows in a self-hosted setup, you must build them yourself, use a separate tool, or evaluate DataHub Cloud against your data residency rules. Check the current DataHub comparison page before you decide, because the edition boundaries can change.
How is a DeployOpen engagement scoped, and is ongoing support a retainer?
Most DeployOpen engagements are fixed-scope. The scope, deliverables and timelines are agreed in writing before work starts, so you can review exactly what will be planned, implemented, integrated, hardened, backed up, documented and handed over. Work can cover the DataHub deployment inside your own cloud account, data center or air-gapped network, SSO integration and connector setup. Ongoing support, upgrades and continuous testing are available as retainers, which you can add after the fixed-scope work or use separately. Ask for the deliverables list, acceptance criteria and the handover plan in the scope document.
How do I get a quote from DeployOpen?
DeployOpen does not publish a price list. A quote follows from the written scope, so the most useful step is to describe your environment, the sources you need to connect, your identity provider, your compliance obligations and whether you need upgrades or a retainer. Include the number of environments, the approximate number of data domains, and any air-gapped or on-premises constraints. The scope document then sets out the deliverables and timeline that the quote covers. When you compare quotes, check whether each one includes migration from your current catalog, testing, documentation and post-handover support.
How DeployOpen helps you evaluate, implement and migrate
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so the Atlan vs DataHub decision can be tested against your real sources and access model. Engagements are fixed-scope, with scope and deliverables agreed in writing before work starts.
How we scope
- Inventory the sources, connectors and on-premises or VPC-locked systems your catalog must reach
- Record which Atlan features your teams rely on, such as glossary workflows, domains and access policies
- Define the written scope, deliverables and timeline for the DataHub evaluation or migration before any work starts
- Confirm whether DataHub Cloud features like compliance forms or access requests are required, or whether open source covers them
How we build
- Deploy DataHub on your Kubernetes cluster with Helm, including Kafka, the database, search and graph index dependencies
- Configure OIDC single sign-on against your identity provider and document the frontend settings you own
- Re-ingest priority sources with DataHub connectors and check column-level lineage against known pipelines
- Test ingestion schedules, resource sizing and upgrade paths in a non-production environment first
How we hand over
- Deliver architecture, runbooks and configuration documentation for your platform and security teams
- Provide a tested upgrade procedure that covers the system-update job and search reindexing steps
- Walk through glossary, domain and ownership conventions so stewards can maintain metadata after handover
- Prepare evidence of access controls and configuration for your own compliance assessors, who issue any formal opinion
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the initial engagement
- Review DataHub releases and plan upgrades against your change windows and approval process
- Run security testing of the deployed catalog and its APIs on a scope agreed in writing
- Ask for a written quote based on your scope, since DeployOpen does not publish a price list
