Amundsen vs Unity Catalog.
Amundsen and Unity Catalog both anchor in catalog & discovery — 2 dimensions differ, 6 hold. Below: posture, coverage diff, and capability matrix.
The Lyft-born OSS catalog that invented search-first discovery — historically important, but development has largely stalled since 2024.
Open-source universal catalog for data and AI under Apache-2.0 — Iceberg-REST and Hive-MS compatible, Databricks-led, LF AI hosted.
Teams that already run Amundsen and need to understand what they have, or teams with a genuinely minimal requirement — usage-ranked table search and ownership tracking, nothing more — who are comfortable owning a codebase that is no longer moving.
Engineering teams that want a vendor-neutral, open-API governance layer for tables (Delta, Iceberg via UniForm, Parquet), volumes, and AI models — particularly when an engine-portable Iceberg REST endpoint matters more than a polished discovery UI.
What each is betting on.
Honest read: maintenance mode. Created at Lyft, open-sourced October 2019, joined LF AI & Data as an incubation project in August 2020. Development has slowed to near-zero — the last release was databuilder 7.5.1 (August 2024) and the last commit to the monorepo (April 2025) moved a maintainer to emeritus status. Stemma, the managed-Amundsen company founded by an Amundsen co-creator, was acquired by Teradata in 2023 and discontinued as a standalone product. The repo is not archived, but treat this as software that is no longer evolving.
Open-sourced June 12, 2024 at Databricks Data + AI Summit under Apache-2.0; donated to LF AI & Data Foundation as a sandbox project. Positioned as 'the industry's only universal catalog for data and AI' with Iceberg REST and Hive metastore API compatibility. Important caveat: the OSS is materially less feature-rich than the Databricks-managed Unity Catalog — it lacks automated lineage, fine-grained access-control UI, and most governance polish as of v0.4 (April 2026). The OSS is a registry; the managed product is a catalog.
Each tool's current strategic narrative, verbatim from its profile.
Spec sheet diff.
| Amundsen | Unity Catalog | |
|---|---|---|
| Vendor | LF AI & Data Foundation | Databricks |
| OpenLineage | Consumer | None |
| Founded | 2019 | 2024 |
| HQ | — | San Francisco, CA |
Full Amundsen pricing → Full Unity Catalog pricing →
Both share Primary cluster: Catalog & discovery · Deployment: Self-hosted only · License: Open source · Pricing: OSS · paid tiers · Free tier: Yes · OSS self-host: Yes · dbt integration: Plugin · Status: ● active
Each tool's center of gravity.
| Cluster | Amundsen | Unity Catalog |
|---|---|---|
| Catalog & discovery | 3/3primary | 2/3primary |
| Lineage & metadata | 1/3 | 0/3 |
| Quality & testing | 0/3 | 0/3 |
Scored 0–3 per cluster on the same rubric across all tools. A 0 means the cluster isn't the tool's focus, not that the feature is absent. See the methodology.
Where they cover different ground.
The declared feature set.
0 of 1 declared features differ — listed first.
These are each tool's self-declared key_features; a blank dot means
undeclared, not impossible.
| Feature | Amundsen | Unity Catalog |
|---|---|---|
| Table-Level Lineage Lineage & metadata |
Where they disagree.
Catalog & discovery
0 of 9 differNo disagreement on any of the 9 capabilities in this cluster — they match across the board.
When to pick each.
Teams that already run Amundsen and need to understand what they have, or teams with a genuinely minimal requirement — usage-ranked table search and ownership tracking, nothing more — who are comfortable owning a codebase that is no longer moving. The core idea still holds up: index tables, dashboards, and people into Elasticsearch, rank results by query-log usage so the tables analysts actually trust float to the top, and keep the UX focused on the single question "which table should I use?" Databuilder's pull model is plain Python, so extending it from an existing Airflow deployment is straightforward for a data platform team.
Engineering teams that want a vendor-neutral, open-API governance layer for tables (Delta, Iceberg via UniForm, Parquet), volumes, and AI models — particularly when an engine-portable Iceberg REST endpoint matters more than a polished discovery UI. The strongest fit is for organisations standardising on open table formats and wanting one catalog readable by Spark, Trino, DuckDB, and Snowflake (via Iceberg REST). Also a defensible choice for teams already on Databricks who want to keep the same governance model when data spills onto other engines.
What each does best.
Amundsen stands out for
- Pioneered usage-ranked, search-first discovery — PageRank-style ranking from query logs remains a genuinely good idea that successors copied
- Deliberately small surface area — analysts get table search, owners, column stats, and previews without a governance platform's learning curve
- Apache-2.0 under neutral LF AI & Data governance, with nothing held back for a paid tier
- Databuilder is plain-Python ETL — custom extractors are easy to write and schedule from an existing Airflow deployment
Unity Catalog stands out for
- Apache-2.0 with project governance moving to LF AI & Data Foundation — credible neutral home
- Iceberg REST catalog API compatibility means UC-cataloged data is readable by Spark, Trino, DuckDB, dbt, Daft, and Snowflake (via Iceberg REST)
- Universal asset model — tables, volumes (files), functions, and AI models in one catalog
- Strong launch ecosystem — AWS, Azure, GCP, NVIDIA, dbt Labs, Fivetran, Confluent, Salesforce, Unstructured
Tools both also compete with.
All Amundsen alternatives, scored →All Unity Catalog alternatives, scored →
A note on this comparison.
Every capability value above traces to Amundsen or Unity Catalog's own structured spec, which links back to its source — nothing here is averaged or smoothed across the two.
Notice something inaccurate? Send a correction.