When to choose DataHub over Amundsen after the archive
If your catalog runs on Amundsen today, the decision is no longer about a project that is still moving. The Amundsen README states that the project was archived in September 2026 due to inactivity, and the amundsen-io/amundsen repository is read-only, so no further fixes or features will come from upstream. DataHub is the stronger choice when you need an actively released platform with a broader feature set. Its README lists more than 150 integrations, including Snowflake, BigQuery, Databricks, dbt, Looker and Tableau, and it covers column-level lineage, a business glossary, ownership, usage and data quality assertions. Its v1.8.0 release candidates followed the v1.6.0.3 release in September 2026, so you can expect ongoing change, which also means you must plan regular upgrades.
Staying close to the Amundsen model still makes sense when the catalog is small, centered on Python, and already understood by the people who maintain it. Amundsen's databuilder loads metadata through a Python script or an Airflow DAG, and that approach may be easier to keep than a new Kafka, database, search and graph stack. Be realistic about the risk: the last service releases were in March 2024 and the last databuilder release was in August 2024, so any Amundsen setup you keep is now self-maintained. If you stay, confirm which Python and Node versions your services need, and who will patch dependencies and respond to security issues without upstream support.
The decision turns on three things. First, the services your team will operate: DataHub needs Kafka, a MySQL or PostgreSQL database, Elasticsearch or OpenSearch and a graph index, while Amundsen's Neo4j or Atlas backend is the piece you would retire. Second, identity integration: DataHub supports OIDC providers such as Google, Okta and Azure AD, and on self-deployed DataHub Core your operator configures the frontend, so confirm how your identity provider and group mapping will work before you choose. Third, the metadata volume you must migrate. Count your tables, dashboards, owners and tags in Neo4j, then test the move on a copy so you can measure the effort before you commit.
Which platform fits which scenario for DataHub vs Amundsen
This table maps common team situations to the platform that fits better and the condition that decides it. Amundsen's last service releases date from March and August 2024 and its repository was archived in September 2026, so treat it as a platform to migrate off rather than one to extend. Read each row as a starting point and confirm the conditions against your own estate.
| Scenario | Better fit | Condition that makes it so |
|---|---|---|
| Amundsen on Neo4j with no capacity to rebuild now | Stay briefly, then plan a move to DataHub | Amundsen is archived and read-only, so no fixes are coming; a read-only export or connector can keep metadata available while you plan the cutover |
| Need lineage, glossary and governance beyond discovery | DataHub | DataHub's README lists column-level lineage, a business glossary, profiling and data quality assertions, while Amundsen's README centers on discovery and search |
| Hadoop, Hive or Ranger estate | DataHub, after checking Atlas | Confirm whether Atlas already meets your governance needs; DataHub is the subject of a separate comparison for Atlas-based estates |
| Want managed hosting with an SLA | DataHub Cloud | DataHub's README describes DataHub Cloud as managed and SLA-backed; confirm the SLA terms and features in writing before you buy |
| Self-hosting with platform engineers on Kubernetes | DataHub Core | You will run Kafka, a MySQL or PostgreSQL database, Elasticsearch or OpenSearch and a graph index yourself, so confirm you have capacity for those services |
| Python-only catalog with light operations | Confirm fit before choosing | Amundsen's Python 3.8 requirement and Node v12 dependency are dated, and DataHub runs on Kubernetes with more services; test both against your team's skills |
How DataHub's services replace the Neo4j and Elasticsearch stack
Amundsen runs three application pieces over a graph store and a search index. DataHub splits its work across a metadata service, consumers, a frontend and several stateful backing services. The cards below show what each piece does and what the operator takes on when moving to it.
Amundsen's three application services
Amundsen runs a Flask application with a React frontend, a search service backed by Elasticsearch, and a metadata service that stores its graph in Neo4j or Apache Atlas. Before planning a move, inventory which of those persistent layers your current deployment uses, since the export path depends on it. Confirm the Python 3.8 and Node v12 requirements still match the hosts you have, because the project is now archived and its last releases date from 2024.
DataHub's GMS and consumer pipeline
DataHub's metadata service (GMS) sits at the center, with MAE and MCE consumers processing metadata change events streamed through Kafka. Changes are written to storage and indexed for search asynchronously rather than through a single application write path. Plan for the consumers as separately scaled components, and check how your team will monitor consumer lag when a metadata source produces a burst of changes.
Kafka, database and search as operator-run services
A production DataHub install relies on Kafka for streaming changes, MySQL, PostgreSQL or MariaDB for storage, and Elasticsearch or OpenSearch for search. Amundsen's search service had one external dependency beside its metadata store, so this is the largest change in what you operate. Decide early whether these services will be managed by your platform team or run inside DataHub's Helm prerequisites chart, and document backup and restore for each.
Graph index on Neo4j or Elasticsearch
DataHub's Kubernetes guide lists a graph index that runs on either Neo4j or Elasticsearch, so teams who want to keep Neo4j can do so, while others can avoid running a separate graph database. This choice replaces Amundsen's direct Neo4j dependency and affects memory sizing and backup scope. Ask your DataHub deployment owner which graph backend is in the design and whether it is supported for the version you plan to run.
Upgrades with the system-update job
DataHub's Helm chart runs a system-update job on upgrades to apply schema changes and reindex search indices when needed. Amundsen upgrades meant managing each service separately, while DataHub upgrades touch the stateful stores as well. Schedule upgrade windows that account for reindexing time on your largest metadata set, and rehearse the job in a non-production cluster first.
Memory and on-call effort
The Docker quickstart requires 8 GB of RAM, and the Kubernetes guide says more than 7 GB is needed to run DataHub and its dependencies on Minikube. Both figures are evaluation guidance, not production sizing. Production memory depends on Kafka, search, database and graph choices, so ask your team to size each service in a staging cluster and to define who is paged when consumer lag or search indexing fails.
How DataHub and Amundsen compare on discovery, lineage and governance
This table compares DataHub and Amundsen on the capabilities the supplied documentation covers, plus the runtime each one needs. Where the sources are silent, it names what to confirm in each product's docs before you decide. Read it as a starting checklist for a migration or a new catalog, not a full feature audit.
| Capability | DataHub | Amundsen |
|---|---|---|
| License | Apache-2.0, with DataHub Cloud sold separately by the company behind it | Apache-2.0, hosted by the LF AI and Data Foundation |
| Release activity and status | Active: v1.6.0.3 released September 25, 2026, with v1.8.0 release candidates following in October 2026 | Archived in September 2026 for inactivity; the repository is read-only, with last service releases dated March 2024 and August 2024 |
| Discovery and search | Elasticsearch or OpenSearch search backed by a metadata service (GMS); confirm ranking behavior in its docs | Elasticsearch-backed search with usage-based, page-rank style ranking of tables and dashboards |
| Column-level lineage | Listed as a core feature in the README; confirm supported sources in the docs | Not covered by the supplied facts; confirm in the Amundsen README before relying on it |
| Business glossary | Listed as a core feature in the README | Not covered by the supplied facts; confirm in the Amundsen docs |
| Data quality assertions | Assertions and monitoring listed in the README; confirm which checks run on which platforms | Not covered by the supplied facts; confirm whether any quality feature exists in your deployment |
| SSO | OpenID Connect; self-deployed Core needs the frontend configured by the operator, while DataHub Cloud enables OIDC through its interface | Not covered by the supplied facts; confirm the authentication options in your Amundsen frontend configuration |
| Integration breadth | More than 150 integrations, including Snowflake, BigQuery, Databricks, dbt, Looker and Tableau | Ingestion through the databuilder library and its extractors; confirm the connector list for your sources |
| Ingestion model | Both push and pull ingestion, with Kafka streaming metadata changes | Databuilder loads metadata with a Python script or an Airflow DAG that imports the library |
| Required runtime | Kafka, MySQL, PostgreSQL or MariaDB, Elasticsearch or OpenSearch, and a graph index on Neo4j or Elasticsearch on Kubernetes | Python 3.8 or later and Node v12, with Neo4j or Apache Atlas as the metadata store |
What licensing and editions mean for each platform
DataHub Core is the open-source distribution of DataHub, licensed under the Apache License 2.0. You download it, run it and upgrade it inside your own cloud account, data center or air-gapped network. The license itself carries no fee, so the spending moves to the infrastructure and the engineers who keep it running. Your team operates the metadata service, the Kafka streams that carry metadata changes, the MySQL or PostgreSQL storage and the Elasticsearch or OpenSearch search layer.
- License terms: Apache License 2.0 permits use, modification and redistribution, so internal extensions do not need a commercial agreement. Have legal confirm attribution and notice obligations for your distribution.
- Who pays for what: you pay for compute, storage, Kafka, search and the staff hours to patch, back up and upgrade them.
- Single sign-on: on DataHub Core, the operator configures the frontend server for OpenID Connect providers such as Okta or Azure AD.
- Upgrades: the Helm chart runs a system-update job that applies schema changes and reindexes search when needed, so schedule a maintenance window and rehearse it.
- Release cadence: v1.6.0.3 was released on September 25, 2026, with v1.8.0 release candidates following in October 2026. Pin versions and track release notes.
Confirm with your security team which release line is approved and who owns the operational runbooks.
DataHub Cloud is the commercial offering from the company behind DataHub. The DataHub README describes it as managed, SLA-backed and enterprise-ready, with no infrastructure for your team to run. Access is governed by a commercial agreement with the vendor rather than by the Apache License 2.0 that covers Core. The trade is clear: you give up direct control of the runtime in exchange for vendor operation and contracted service levels. Your team still owns integrations, access policies and the metadata itself.
- Operating model: the vendor runs the platform, so your effort shifts to source connections, identity configuration and governance workflows. Ask which tasks remain with you.
- Service levels: the README uses the phrase SLA-backed. Request the written service levels, measurement method, remedies and exclusions.
- Feature sets: this page does not list which capabilities sit in which Cloud plan, so ask for the current feature matrix and mark which items are add-ons.
- Data location: ask where metadata is stored, which regions are available and how your residency and audit requirements will be met.
- Exit terms: ask how metadata can be exported, in what format and within what timeframe if you later move to a self-hosted deployment.
Get the feature matrix, SLA document and data processing terms in writing before comparing a Cloud quote with a self-hosted scope.
Amundsen is licensed under Apache-2.0 and is hosted by the LF AI and Data Foundation. Its README states that the project was archived in September 2026 due to inactivity and that its contents remain available for historical purposes. The amundsen-io/amundsen repository is read-only, so no new releases or security fixes will come from the project. For teams still running it, the license question is less important than the maintenance question: who will patch the frontend, metadata, search and databuilder components from now on.
- License: Apache-2.0 lets you keep running and forking the code, but every future fix becomes your responsibility or your contractor's.
- Hosting and status: foundation hosting does not change the archived status. Record the archive notice as a standing risk item.
- Last releases: frontend 4.3.0, metadata 3.13.0 and search 4.2.0 shipped on March 6, 2024, and databuilder 7.5.1 on August 14, 2024. Check dependency and runtime support against your security baseline.
- Runtime requirements: the README lists Python 3.8 or later and Node v12. Verify these against what your hosts and scanners currently accept.
- Migration input: OpenMetadata documents a connector that reads from Amundsen's Neo4j backend over a read-only account, which helps with planning an exit.
Ask your security team to log the archive as a risk and set a dated decision point for migration.
What drives the running cost of DataHub and Amundsen
The recurring infrastructure cost of DataHub comes from the services around its own components. The Kubernetes guide describes GMS, the MAE Consumer, the MCE Consumer and the Frontend, which need Kafka, a MySQL, PostgreSQL or MariaDB database, Elasticsearch for search and a graph index on Neo4j or Elasticsearch. Amundsen's footprint is smaller on paper: a search service on Elasticsearch and a metadata service backed by Neo4j or Apache Atlas. Count every stateful service in each design, then ask whether Kafka, the database and search can be shared with platforms you already operate and who pays for their capacity, backups and patching. The 8 GB Docker quickstart is for evaluation only and should not be used to size a production install.
Staff skills and upgrade effort are where the two platforms differ most. DataHub in production assumes Kubernetes and Helm experience, since the deployment uses the acryldata/datahub-helm charts and a separate prerequisites chart, as described in the DataHub Kubernetes guide. Each upgrade runs a system-update job that applies schema changes and reindexes search when needed, so the upgrade window must allow for reindex time, and you should rehearse it on a copy of production. Amundsen's last service releases date from March 2024 and its databuilder from August 2024, and the repository is archived. Any fix or upgrade on that stack becomes internal engineering work that you carry alone.
Separate one-time migration work from recurring operations when you build the budget. One-time work includes standing up DataHub, moving metadata out of Neo4j, rebuilding ingestion, configuring OIDC SSO and validating lineage. Recurring work covers infrastructure, upgrades, security patching, on-call and any subscription to DataHub Cloud, which adds vendor support and a managed service with no infrastructure to run. Confirm DataHub Cloud pricing and SLA terms with its vendor, because no figures are supplied here. DeployOpen does not publish prices. A quote follows from a written, fixed scope that lists the components, hosting environment, ingestion sources and deliverables, and any ongoing support is priced as a separate retainer.
How to move metadata off Amundsen without losing lineage
This sequence moves Amundsen's table, dashboard and lineage metadata into DataHub in a checked order, so that search, ownership and lineage can be verified before Amundsen's scheduled jobs are switched off. Each step ends with a check that the team can record as evidence.
Inventory Amundsen sources and databuilder jobs
The platform or data engineering owner lists every source that Amundsen indexes, each databuilder job or Airflow DAG that loads it, and the Python scripts or libraries involved, including any amundsengremlin or amundsenrds loaders. Record which Neo4j or Apache Atlas backend holds the graph, which Elasticsearch index serves search, and which jobs run on a schedule. The step is done when every source has one owner and one loader recorded in a shared inventory that the team has reviewed.
Choose the extraction path
Decide whether to read metadata directly from the Neo4j backend, or to re-run the databuilder jobs against the original sources and send the output to DataHub. Direct extraction keeps Amundsen's existing graph as the record, while re-running the loaders produces metadata shaped by current source connectors. OpenMetadata's documented Amundsen connector is one read path to evaluate: it reads from Neo4j over a Bolt URI with a read-only account, includes tags by default, and assigns owners only where the source owner's email matches a user. Confirm with the team that the chosen path can be run against a read-only account, and record the decision with its reason.
Map owners, tags and glossary terms
Build a mapping table that links each Amundsen owner to a DataHub user identity, and each Amundsen tag to a DataHub tag or glossary term. Owners whose email addresses match the identity provider will carry over cleanly, and unmatched owners need a manual decision, such as assigning a team or a data steward. Review the mapping with the data owners who will be accountable for the assets. The step is complete when every owner and tag in the inventory has a documented target and the unmatched list is closed or accepted.
Load metadata through DataHub ingestion
Run ingestion into DataHub for the sources in scope, using DataHub's ingestion framework with the source connectors that match each system, or push metadata produced by the extraction step. Start with one non-production source so the team can see how datasets, schemas and ownership appear in the DataHub interface. Confirm the DataHub deployment is reachable and has the services it needs, such as GMS, Kafka, a MySQL or PostgreSQL database and Elasticsearch or OpenSearch, before loading at scale. The step is done when a sample of datasets shows the expected schema, owner and tags.
Validate search, ownership and lineage
Compare a sample of assets in Amundsen with the same assets in DataHub. Check that search returns the expected datasets for common terms, that owners and tags match the mapping, and that upstream and downstream lineage is complete for critical tables. DataHub lists column-level lineage among its features, so confirm that column lineage is present where Amundsen recorded it, and record any gaps. Ask the business owners of the most important assets to sign off on the results. The step is done when the agreed validation checklist passes or each failure has a documented fix.
Rebuild search, SSO and custom behavior
Recreate the parts that do not transfer as data. This includes search configuration and ranking, which in Amundsen relied on usage-based page-rank style ordering, along with SSO, which on self-deployed DataHub Core is configured on the frontend server through OIDC. Also review any Python customizations in the databuilder code or Amundsen forks and decide whether each one is needed in DataHub. Document each rebuilt item with its owner and test it with users before cutover. The step is done when users can sign in through the chosen identity provider and the rebuilt search behavior has been accepted by the team.
Retire Amundsen's Airflow DAGs and services
After validation, pause the Airflow DAGs that run Amundsen's databuilder jobs, then disable the scheduled loads and keep the final Neo4j, Elasticsearch and service configurations as a read-only archive. Remove the Amundsen frontend, metadata and search services from the users' entry points once the team has confirmed that DataHub is the working catalog. Keep a dated export of the Amundsen graph for audit or historical reference, since the Amundsen README notes that the project is archived but its contents remain available. The step is complete when no Amundsen loads are scheduled and the archive and cutover record are stored with the change ticket.
Where DataHub and Amundsen projects usually run long
On a DataHub move, the longest stretch is usually the production foundation rather than the first ingestion run. The Kubernetes guide pairs a separate prerequisites chart with the main Helm charts, and a production install should point at external Kafka, a MySQL, PostgreSQL or MariaDB database, and Elasticsearch or OpenSearch rather than in-cluster copies. Each of those services needs sizing, backup, patching and network policy owned by someone on your team. Self-deployed DataHub Core also requires the operator to configure OIDC on the frontend server, so identity provider settings, redirect URIs and group claims need sign-off before cutover. Ingestion connectors then have to be set up source by source across the estate, with credentials, scheduling and ownership for each. Confirm which of these pieces your organization will run itself and which, if any, you expect to buy as DataHub Cloud, because that choice sets the scope of everything else.
On the Amundsen side, the work is different and mostly defensive. The project was archived in September 2026 and its repository is read-only, so no security fixes or dependency updates will arrive from upstream. If you keep the stack running, you own the Python and Node runtimes, the Neo4j or Apache Atlas persistence layer, the Elasticsearch search service, and the Airflow DAGs that run databuilder, whose last release was 7.5.1 on August 14, 2024. If you extract instead, the common overruns are unmapped owner identities, since OpenMetadata assigns owners only when a source owner's email matches an existing user; custom databuilder extractors that have no equivalent in the target; and lineage gaps where the graph in Neo4j does not carry the edges your analysts rely on. Before committing to scope, run a sample reconciliation of owners, tags and lineage paths, and confirm the target platform's connectors cover every source you index today.
Questions teams ask before moving off Amundsen
Does Amundsen still work now that it has been archived?
Yes, the code still runs, but no one is maintaining it. The Amundsen README states the project was archived in September 2026 due to inactivity and that its contents remain available for historical purposes, and the GitHub repository is read-only. The last service releases were frontend 4.3.0, metadata 3.13.0 and search 4.2.0 on March 6, 2024, and the last databuilder release was 7.5.1 on August 14, 2024. Nobody will publish security fixes or compatibility updates for those versions. Your exposure grows with each dependency that moves on without Amundsen, including the Neo4j or Apache Atlas persistence layer, Elasticsearch and the Python and Node runtimes. Ask your security team to record that risk in your register so the move has a clear owner and date.
What does a DataHub migration cost, and why does the quote depend on scope?
The cost is driven by the work, not by a fixed package, and no price is published for either path. Cost components include the infrastructure you run for DataHub and its services, the labor to stand up and harden the platform, the effort to rebuild or re-point your ingestion, and the work to validate that users and owners carried over correctly. DataHub Core is open source under Apache-2.0, so the license itself carries no fee, while DataHub Cloud is a paid managed service. Most engagements are fixed-scope, so the written scope drives the quote. Ask for a quote that lists each source system, the number of Amundsen metadata objects to move, the identity setup, and what you will own afterward.
How long does moving metadata off Amundsen take?
The duration depends on how many sources you feed into Amundsen, how much of its metadata your teams actually use, and how many environments you must build. No supplied source gives a duration for this migration, so treat any timeline as unknown until scoped. The main drivers are the number of ingestion pipelines to rebuild, whether your Amundsen graph is in Neo4j or Atlas, the number of identity and access rules to recreate, and the validation period your users need before cutover. A small estate with one Airflow-based ingestion path will take less time than a large estate with many Python-loaded sources. Ask the implementation partner to break the timeline into discovery, build, cutover and handover phases.
Can our team migrate from Amundsen to DataHub without outside help?
Your team can do it if it already runs Kubernetes, Kafka and a relational database in production and has time to learn DataHub's components. The DataHub Kubernetes guide describes four main components, GMS, the MAE Consumer, the MCE Consumer and the Frontend, plus Kafka, a MySQL, PostgreSQL or MariaDB database, Elasticsearch for search and a graph index on Neo4j or Elasticsearch. Deployment uses Helm charts from the acryldata/datahub-helm repository and a separate prerequisites chart. Teams without this background often underestimate the work to size, secure and upgrade those services. A useful check is to write down who will run upgrades, including the system-update job that applies schema changes and reindexes search when needed, and who will own the ingestion connectors after cutover.
What skills and services does our staff need to run DataHub Core?
Your staff needs working knowledge of Kubernetes, Kafka, a relational database, Elasticsearch or OpenSearch and an identity provider. DataHub supports single sign-on through OpenID Connect providers such as Google, Okta and Azure AD. On self-deployed DataHub Core, the operator configures the frontend server for OIDC, so identity work falls to your team. Plan for capacity as well: the Kubernetes guide says more than 7 GB of RAM is needed to run DataHub and its dependencies on Minikube, and production sizing will differ. Confirm with DataHub which Kafka, database and search versions are supported for the release you choose, and confirm your identity provider settings before cutover.
Should we run DataHub Core ourselves or buy DataHub Cloud?
Choose DataHub Core if you want to own the infrastructure and can staff its Kafka, database, search and graph services. Choose DataHub Cloud if you want the vendor to run the platform and you value its SLA and managed operations. DataHub's README describes Cloud as managed, SLA-backed and enterprise-ready with no infrastructure to run, while Core is the Apache-2.0 open-source build you deploy yourself. Cloud-only capabilities are listed in the sibling comparison of DataHub Cloud and self-hosted DataHub, so review that before deciding. Whichever you pick, ask for the cost of each path in writing, including recurring infrastructure and support, and compare it against the staff hours you would otherwise spend running the stack.
How DeployOpen helps choose, implement or migrate a metadata platform
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a team moving off Amundsen, that means starting with a written picture of what discovery, lineage and governance your users rely on today, then deciding whether DataHub Core, the managed DataHub Cloud or another option fits that picture.
How we scope
- Inventory the Amundsen deployment, including its Neo4j or Apache Atlas metadata store, Elasticsearch search and any databuilder jobs feeding it.
- Record which sources, dashboards, glossary terms and owners must carry over, and which can be retired without losing audit history.
- Agree the target architecture, the target edition and the deliverables in writing before work starts, since most engagements are fixed-scope.
How we build
- Stand up DataHub in your cloud account, data center or air-gapped network, with the Kafka, database, search and graph services you choose to run.
- Configure ingestion for each source, and rebuild the Amundsen-era owner, tag and glossary mappings as a tested import with reconciliation checks.
- Test single sign-on against your identity provider and document the access model, backup routine and upgrade procedure for your platform team.
How we hand over
- Deliver runbooks for deployment, the system-update job on upgrades, search reindexing and recovery, written for your operators.
- Walk your data owners through search, lineage and glossary use, and record which users and teams now depend on which metadata views.
- Provide a cutover record listing what was migrated, what was intentionally left behind and how the read-only Amundsen archive is kept for reference.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, so the platform keeps pace with DataHub releases after handover.
- Confirm the release line you will run, and agree in writing how security patches and version upgrades are tested before they reach production.
- Ask any quote to state which items are one-time (scope, migration, handover) and which recur (retainer hours, upgrades, testing).
