Amundsen

Editor’s note: This Amundsen review assesses documented behavior. The upstream project was archived in September 2026; I have not benchmarked a deployment.

Quick verdict: I would skip Amundsen for a new data catalog deployment and shortlist maintained alternatives instead. I recommend retaining an existing installation only when it still serves a defined discovery need and your team can own its maintenance.

The Amundsen data catalog still addresses a familiar problem: finding the right dataset without asking around in chat. Its search-first approach connects technical metadata with the context people need before writing a query. Within catalogs and governance, I see it primarily as a data discovery tool, not a complete system for enforcing trust.

In this review, I’ll weigh the discovery workflow against operating costs, ingestion responsibilities, and governance limits. I’ll also explain when keeping an existing installation makes sense.

Key Takeaways

• Upstream is archived: The project was archived due to inactivity, making it a poor default for new deployments.
• Existing installations can retain value: Search and asset context can still support a bounded discovery workload.
• No upstream license fee: Self-hosting still requires infrastructure and engineering.
• Lineage requires supplied relationships: Table and column capabilities do not guarantee complete dependency coverage.
• Discovery is not authorization: Finding a dataset does not grant access to its records.

Pros and Cons

I like Amundsen’s focused discovery model. My reservations concern the work needed to sustain it, rather than the usefulness of searchable metadata.

How Much Does Amundsen Cost?

Amundsen is available as self-hosted open-source software:

• Self-hosted open source ($0 license fee): Apache License 2.0 software for teams running their own deployment, with no upstream subscription or per-seat charge.

That is the software price, not the cost of providing a dependable internal service. There is no upstream paid tier to upgrade into when maintenance becomes difficult, and the archived project does not provide a commercial service-level agreement.

Cost component	Price or cost basis	Budget responsibility
Self-hosted Amundsen license	$0	No upstream subscription
Hosting and storage	Variable infrastructure costs	Application, search, and metadata services
Ingestion jobs	Variable compute and engineering	Extraction, scheduling, and indexing
Production operations	Variable staff and infrastructure costs	Monitoring, backups, and recovery
Security and compatibility	Variable engineering costs	Dependency patches and integration changes
Customization or migration	Variable project costs	Internal extensions and metadata transfer

I would budget for Amundsen as an internal software service, rather than a free application. Someone needs responsibility for failed ingestion even when the interface remains available. Someone also needs to handle dependency changes that have nothing to do with the catalog’s business value.

A smaller metadata footprint may reduce infrastructure needs, but it does not remove those responsibilities. For a lean platform team, the opportunity cost matters: an engineer maintaining catalog plumbing is not improving the pipelines that populate it.

Is Amundsen Good Value for Money?

The value calculation is different for an established deployment and a fresh installation:

• Existing, useful deployment: Retaining it temporarily can preserve an established discovery workflow while avoiding a rushed migration.
• Existing, neglected deployment: A low hosting bill is weak justification if nobody trusts the descriptions or maintains ingestion.
• New deployment: I would put implementation effort into an alternative with a sustainable maintenance path.

I would compare the future cost of keeping Amundsen dependable with the cost of moving its useful metadata elsewhere.

Reviewer’s Notes

For an existing platform team, my recommendation is the self-hosted offering only with a named maintenance owner and an explicit operating budget. For a team choosing its first catalog, I would not start with Amundsen simply to avoid license fees.

Getting Started With Amundsen

Getting started means assembling a metadata service, not creating a hosted account. For someone inheriting an installation, understanding the path from source to search result is more valuable than simply knowing how to open its homepage.

The architecture separates the React/Flask frontend from a search service backed by Elasticsearch and a metadata service. Metadata backend options include Neo4j and Apache Atlas, while Databuilder handles ingestion.

The historical Docker quickstart illustrates the basic flow:

1. Prepare the local stack. The setup uses the repository and Docker/Compose prerequisites, with a choice of Neo4j or Atlas configuration.
2. Load sample metadata. Starting containers is separate from populating the catalog; the Neo4j path includes a sample data loader.
3. Open the frontend. The example uses local port 5000 and a search for test to reach sample assets.
4. Move beyond the demonstration. Real-source ingestion and production security are separate work.

I would treat that as a historical demonstration, not a promise that old commands and dependencies will work unchanged today. It also says little about production capacity or secure exposure.

For the everyday user journey, imagine a hypothetical retailer with orders_raw and orders_reporting. An analyst searching for orders needs to decide which dataset belongs in a weekly revenue report.

The useful sequence is:

1. Find a candidate. Search for the dataset name or relevant descriptive text.
2. Inspect its meaning. Read the description and columns to understand what each row represents.
3. Identify responsibility. Look for an owner who can explain ambiguous business rules.
4. Resolve the ambiguity. Determine whether canceled orders belong in the intended calculation before querying the source.
5. Preserve the answer. Where write access permits, improve the description or ownership information for the next person.

Amundsen’s table APIs support description and owner updates, but that does not mean every user automatically receives write access. The deployment determines how people contribute.

What I like about this workflow is its modest goal: make the next decision easier. A catalog does not need to answer every analytical question if it can point someone toward the right dataset and responsible person.

The operator’s journey continues after that first successful search. Real metadata must reach the backend and search index on a recurring basis. For an inherited installation, the central handover question is who owns each step, including the point where a source change becomes visible to catalog users.

Finding Data With Amundsen

Amundsen searches ingested metadata, not every record in your warehouse. That distinction makes it useful for locating assets, but it also explains why an undiscoverable table may reflect an ingestion problem rather than a search problem.

Search v2.1 supports fuzzy matching, word stemming, and usage-based ranking boosts. It also supports multi-value AND/OR filtering when the required mappings are populated. Compatible frontend, search, and Databuilder configuration matter; without the newer mappings, the search proxy falls back to v2.

I like usage as a relevance signal because familiar datasets are often sensible starting points. I would not let that signal make the final decision. Popularity is not correctness, and a heavily queried legacy table can remain popular long after a better replacement exists.

The table model can carry several kinds of context:

• Ownership and explanation: Owners and descriptions help establish purpose and accountability.
• Schema context: Columns help an analyst judge whether the asset contains the required information.
• Usage context: Readers and read counts indicate adoption.
• Status context: Tags, badges, and supplied timestamps or watermarks add signals for interpretation.

Those fields may be empty unless populated. A timestamp also needs a clear meaning: a recent metadata update is not automatically evidence that the underlying business data is current.

My preference is to make a small set of important datasets understandable before chasing catalog-wide coverage. Thousands of entries with unclear names can reproduce the warehouse’s confusion in a second interface.

Descriptions deserve particular attention. For a hypothetical revenue dataset, “contains order information” offers little help; an explanation of row grain and refund treatment gives the reader a decision rule. That improvement comes from stewardship, not ranking.

For teams whose discovery journey increasingly involves dependency investigation, DataHub’s lineage explorer and impact-analysis capabilities make it a relevant shortlist alternative. I would compare the questions users need answered, rather than assume that a larger feature set automatically produces better discovery.

Connecting Sources and Keeping Metadata Useful

In Amundsen, ingestion is ongoing engineering work. Your team owns the jobs that extract metadata, load it into the backend, and publish it to search.

Databuilder provides extractors, transformers, loaders, publishers, and jobs. Jobs can run from Python or an Airflow DAG, allowing teams to fit ingestion into an existing orchestration setup.

The available implementations include bounded, source-specific paths:

• Snowflake: A metadata extractor queries table and column information with configurable extraction behavior.
• BigQuery: An extractor retrieves dataset, table, and column metadata with filtering support.
• Postgres: The tutorial separates a metadata-loading job from an Elasticsearch indexing job.

These implementations do not guarantee compatibility with future source changes. Permissions and configuration still belong to the operator.

The Postgres example exposes an important distinction: loading and indexing are separate. If a new table exists in the metadata backend but remains absent from search, troubleshooting only the warehouse connection misses part of the pipeline.

I would assign ingestion ownership by source, with responsibility extending through search publication. Otherwise, a successful extraction job can become a misleading definition of success.

There is also a practical conflict between automated imports and human edits. Databuilder upserts metadata by default, while create-only configuration can protect table and column descriptions from overwrites. Decide whether source descriptions or catalog edits are authoritative; without that rule, helpful contributions can be replaced on a later run.

My preference is one clearly understood writing location per description type. Asking people to improve documentation while letting another process silently supersede it is a poor stewardship model.

Previews introduce a different dependency. Amundsen can integrate with Superset or another query/results endpoint through a preview client. Production Superset integration must pass impersonation information so access can be checked for the current user.

A preview is therefore not automatic warehouse access. If your team cannot maintain the authorization path, I would favor useful metadata without previews over an attractive feature with unclear access boundaries.

Lineage, Access, and the Limits of Governance

Amundsen supports table and column lineage, but the view depends on relationships your deployment supplies. I would judge its usefulness by those relationships, rather than the presence of a lineage tab.

The table APIs support upstream and downstream lineage retrieval. A column-lineage API supports direction and depth, and the frontend has configurable column-lineage list and page views. Backend support and supplied relationships remain necessary.

The ingestion paths need precise interpretation:

• dbt artifacts: The extractor can ingest model descriptions, columns, tags, and table dependencies.
• OpenLineage event files: The extractor reads table lineage from newline-delimited JSON files.
• Column relationships: API and interface support do not establish that either path automatically provides complete column-level lineage.

For change planning, I would use lineage to identify known dependencies, not certify the absence of unknown ones. A missing edge is not clearance to remove a field.

Governance has similar boundaries. Table and column badges can communicate centrally supplied labels, with metadata configuration and frontend styling required. A sensitive-data badge does not itself detect sensitive information, and a certified label needs an organizational process behind it.

Amundsen can also display externally generated context, including reports through programmatic descriptions. That is useful presentation, not a native quality-testing or PII-detection engine. The external-provider quality-check display is configurable and disabled by default.

Authentication requires deployment work too. The documented OIDC approach configures the frontend, metadata, and search services, including token forwarding and authenticated-user handling. Catalog login and source authorization remain separate concerns.

I also would not treat an action-logging extension point as proof of a complete compliance audit trail. Hooks provide a place to build behavior; they do not establish retention rules or effective oversight.

For stronger metadata permission controls, DataHub documents Admin, Editor, and Reader roles, plus finer-grained policies. For classification-driven governance in an existing Ranger environment, Apache Atlas is relevant because it documents authorization and masking integration.

My view is that Amundsen can organize evidence of trust, but your team must define what that evidence means. If the requirement is enforceable governance rather than findability, start with the required control and work backward to the platform.

How Does Amundsen Compare to Alternatives?

I would shortlist Amundsen alternatives around the job your current catalog cannot do. DataHub and OpenMetadata have active upstream development as of October 2026, which strengthens their case for a new deployment.

• DataHub: My shortlist choice when dependency investigation and metadata permissions matter. Its documented capabilities include table and column lineage visualization in Core OSS and Cloud, plus role-based access and policies. Those metadata permissions still do not grant warehouse access.
• OpenMetadata: Particularly relevant for existing Neo4j-backed Amundsen deployments because it has an Amundsen ingestion connector. Its glossary supports hierarchical terms, related terms, asset associations, and approval workflows, making it worth considering when shared business definitions are the priority.
• Apache Atlas: Most relevant to my shortlist for an established Hadoop, Hive, or Ranger environment. Its documented capabilities include metadata types, classifications, lineage, and search. It can also serve as Amundsen’s backend, so this is not always a simple replacement decision.

Product	Main comparison angle	Relevant capability	Main caveat
Amundsen	Retaining familiar discovery	Metadata search and configurable lineage	Archived upstream; internal maintenance required
DataHub	Dependency investigation	Table/column lineage and impact analysis	Coverage depends on ingested relationships
OpenMetadata	Migration and business definitions	Neo4j-based Amundsen connector and glossary	Import does not imply lossless migration
Apache Atlas	Classification-led governance	Ranger integration and classification propagation	Separate infrastructure and configuration

OpenMetadata’s connector includes a connection-testing and scheduled-ingestion workflow. However, Neo4j import is not universal migration: it does not establish Atlas import or preservation of every custom field and relationship.

I would define the destination around the metadata people rely on. A migration that transfers table names but loses carefully maintained explanations may preserve the inventory while weakening discovery.

There is no defensible “easiest alternative” for every deployment here. The amount of custom ingestion and governance configuration matters more than a generic simplicity claim. My preference is the candidate that removes your most expensive ongoing responsibility without discarding useful context.

How I Reviewed Amundsen

This is an independent assessment, not a hands-on benchmark. I evaluated documented discovery workflows, deployment responsibilities, and metadata capabilities, then separated those specifications from my recommendations.

My judgment distinguishes adopting Amundsen today from retaining an installation that already has useful metadata and operational ownership. I make no measured claims about search speed, installation time, or comparative reliability.

I also distinguish a configurable feature from an end-to-end capability. Lineage views, preview clients, and authentication hooks still depend on integration choices.

License and pricing information is current as of October 2026. Infrastructure and staffing costs are deployment-specific, not quoted prices.

Should You Use Amundsen?

For a new deployment, I would choose another starting point. Amundsen’s focused discovery model does not offset taking responsibility for an archived upstream project before your catalog has delivered any value.

For an existing installation, I would avoid panic-driven replacement. Useful descriptions and familiar discovery habits are assets worth preserving. Keeping the service temporarily can be reasonable when its scope is stable and maintenance has a real owner.

My retention decision would turn on three conditions:

• The workload is bounded: The catalog solves a defined discovery problem rather than accumulating unsupported responsibilities.
• The metadata stays useful: Ingestion ownership and description rules are clear.
• Maintenance is funded: Security and compatibility work are assigned, not assumed.

If those conditions are missing, I would prioritize a deliberate migration. If they are present, continued operation can provide breathing room without pretending the long-term decision has disappeared.

I would retain Amundsen only while its existing value justifies the maintenance work.

Amundsen FAQ

Is Amundsen free?

Amundsen’s Apache 2.0 source has no upstream license fee or per-seat subscription. Running it still costs money through hosting and engineering. I would compare total operating effort, not just the software price, with alternatives.

Is Amundsen still actively maintained?

The upstream project was archived in September 2026 due to inactivity. That does not establish the status of every independent fork. A fork needs its own maintenance assessment rather than inheriting confidence from Amundsen’s history.

What happens to an existing Amundsen installation?

Archiving the repository does not automatically shut down deployed software. The practical change concerns future upkeep. Your organization needs a credible way to handle dependency vulnerabilities and integration changes while deciding whether continued operation remains worthwhile.

Does Amundsen support column lineage?

Yes. Amundsen has a column-lineage API and configurable frontend views, alongside table-lineage capabilities. Coverage depends on backend support and ingested relationships. The dbt and OpenLineage paths discussed here establish table dependencies, not universal automatic column lineage.

What is the easiest alternative for migration?

There is no universal easiest option. OpenMetadata’s Amundsen connector provides a documented path from Neo4j-backed metadata, but not guaranteed lossless transfer. I would also shortlist DataHub for lineage-centered work and consider Atlas where existing governance infrastructure makes it relevant.