You're on Amundsen: The Project Is Archived. Keep the Search, Add the Control Plane Behind It
Amundsen was archived in September 2026. Keep its search running while Data Workers keeps every table people find there right, behind approvals, and gives your metadata a governed home in Data Context Wizard.
Your platform team stood up Amundsen because analysts kept asking in Slack which table to use. Its search box covers tables, dashboards and features, ranked by how often each one is queried, so the table everyone uses shows up first. Each table page shows columns, description, owners, frequent users, last-updated time, tags and badges. Behind it sit the pieces you run yourselves: the metadata service on Neo4j, Elasticsearch for search, and databuilder jobs on Airflow pulling from the Hive Metastore and Postgres. On September 10, 2026 the README gained a new first line: "Due to inactivity, this project was archived in September 2026. The contents will remain available for historical purposes." Your Amundsen still runs; nobody upstream will ship another release. Amundsen is the search engine your people trust. Data Workers is the control plane behind it: it keeps every table people find there right, behind your approvals, and gives your metadata a governed home in Data Context Wizard.
Key takeaways
- •Amundsen keeps its job for as long as you want it. Search, table pages, owners and databuilder keep running on your infrastructure, and the Apache 2.0 code stays available.
- •Data Workers does the work Amundsen was never built for. It detects changes at the source, traces them through Airflow and the lake tables to the table people find in search, proposes the fix and verifies it.
- •The owner approves every change. Fixes arrive as diffs for the owner to merge; reruns are queued through Airflow only after approval, and each one leaves a receipt.
- •Your metadata gets a governed home. Amundsen's metadata comes into Data Context Wizard as proposals your team exports from its REST API, joined to lineage and quality, so the move off Amundsen runs on your schedule.
- •Start with a pilot. One domain, read-only, on the ladder from L0 manual to L4 autonomous.
Amundsen is the search engine. Data Workers is the control plane.
Amundsen answers one question very well: which table should I use? The README calls it "Google search for data". Lyft contributed it to the LF AI & Data Foundation in July 2020, and the foundation's project page now records that its Technical Advisory Committee and Governing Board voted to archive it in September 2026. All 11 repositories in the amundsen-io organization on GitHub are now archived and read-only. The last releases are databuilder 7.5.1 (August 14, 2024) and metadata 3.13.0, search 4.2.0 and frontend 4.3.0 (March 6, 2024).
None of that makes the search box less useful tomorrow. The question behind every result still matters: is the table people find actually right? Here is a Wednesday at an online marketplace that runs its own stack. This is an illustrative example.
| Time | System | What happens |
|---|---|---|
| Tue 16:40 | Postgres | The orders service launches checkout in Canada and the UK. orders gets a currency column, and amount is now stored in the buyer's currency instead of always in US dollars |
| Wed 01:10 | Airflow | The orders_to_lake DAG run copies Tuesday's orders, currency included, into the Hive table raw.orders, registered in the Hive Metastore |
| Wed 02:00 | Trino | The build_daily_gmv task rebuilds finance.gmv_daily with sum(amount). 4,870 orders in Canadian dollars and pounds are added up as if they were US dollars, and Tuesday's gross merchandise value is off by $38,900 |
| Wed 05:00 | Amundsen | The databuilder DAG refreshes Neo4j and Elasticsearch. finance.gmv_daily is still the top result for "gmv", with its owner, 41 frequent users, a fresh last-updated time and the description "daily gross merchandise value in USD". The new column shows up on the raw.orders page. Everything Amundsen shows is accurate; the number in the table is wrong |
| Wed 05:12 | Data Workers | run_quality_check profiles the Postgres source and finds a new currency column. The monitor_metrics baseline flags Tuesday's value in finance.gmv_daily outside its 30-day range, and the owner's query finds 4,870 non-USD orders behind it |
| Wed 05:18 | Data Workers | trace_cross_platform_lineage follows amount and currency from Postgres through the Airflow DAG and the Hive table to the Trino build. blast_radius_analysis lists finance.gmv_daily, two Trino views on top of it and the board metrics extract due Thursday |
| Wed 05:26 | Data Workers | It proposes a diff for the owner to merge: convert amount to US dollars in the Trino build with a join to the daily rates table ref.fx_rates_daily, plus a quality check that fails if a non-USD order reaches gmv_daily without a rate. The plan includes rerunning Tuesday's partition after the merge |
| Wed 08:05 | Slack and Spellbook | The request reaches the finance analytics lead who owns the table, the same person Amundsen lists. She reviews the diff, the blast radius and the rollback in Spellbook and approves |
| Wed 08:40 | GitHub | She merges the diff |
| Wed 08:42 | Airflow and Trino | Data Workers queues the rerun of build_daily_gmv for Tuesday through Airflow and reads its status. The monitor_metrics baseline shows the value back in range, and the owner's query matches it to Tuesday's Postgres orders converted at Tuesday's rates. Data Workers writes the receipt |
| Thu 05:00 | Amundsen | The next databuilder run refreshes the table page. The description change Data Workers proposed, "converted to USD at the daily rate", is in front of the owner |
Amundsen did its part exactly: it sent 41 people to the right table, with the right owner and an honest timestamp, and it even listed the new column. The cause was a change in meaning in an app database three hops upstream, and the fix needed a trace across four systems, a check against the source and an owner's approval. Without it, the board would have seen Canadian dollars and pounds counted as US dollars.
| Job | What Amundsen does | What Data Workers does |
|---|---|---|
| Finding the table | Ranks tables by usage and shows owners, frequent users and descriptions | Reads that metadata over Amundsen's REST API as sourced context next to its own lineage and run history |
| Noticing change | Shows the last-updated time and the columns databuilder read on its last run | Catches schema changes from the dbt manifest diff and run_quality_check profiles, and holds the data to monitor_metrics baselines |
| Finding the cause | Shows table and column lineage where it was loaded | Traces from Postgres through the Airflow DAG and the Hive table to the Trino build |
| The fix | Records the owner to contact | Proposes the diff and routes it to the named owner |
| The proof | Refreshes on the next databuilder run | Queues the rerun after approval, re-checks the result against its baseline and keeps a receipt |
| The record | Holds descriptions, tags and badges edited in the UI | Records the approved fact in the Context Wizard graph and proposes the description change for the owner |
Why doesn't Amundsen just do this itself?
Because Amundsen was built for discovery, and its design follows from that. It harvests metadata on a schedule, indexes it and ranks it by how people use it. Its write surface is its own metadata: the REST API sets descriptions, tags, badges and owners. It reads the Hive Metastore and Postgres and never changes them. That is the right shape for a search engine, and it is why so many teams adopted it.
Amundsen was also a community project, built to solve one problem well and given away under Apache 2.0; the foundation archived it after activity wound down. That is how open-source projects are meant to retire: the code stays open, and the decision about what runs next goes back to the people who run it.
Changing a Trino build, rerunning an Airflow task and proving the result against Postgres is a different product. It needs the code, the blast radius, scoped credentials, a named-owner approval, a verified result, a rollback path and the liability for the change. That product is Data Workers.
Every tool owns a slice. Data Workers covers the whole lifecycle
Amundsen's slice is search and discovery for the tables people use. Each point tool adds another console, contract and handoff. Data Workers covers the whole lifecycle with one context, one approval flow and one audit trail. We score catalogs the same way across our data catalog comparison of Collibra, Alation, DataHub and OpenMetadata. There, DataHub and OpenMetadata tie Data Workers at 9 on Catalog & Context. Amundsen scores 8: its usage-ranked search is excellent, but it has no business glossary and no MCP server, and its feature set is fixed at the 2024 releases.
| Stage | Data Workers | Amundsen | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 8 | Amundsen's home stage: search across tables, dashboards and features, ranked by how many people query them, with owners, frequent users, descriptions and lineage. A point below DataHub and OpenMetadata: no business glossary, no MCP server, and the feature set is fixed at the last release. Data Workers reads it as a source and keeps the meaning current in Data Context Wizard. |
| Analytics & Insights | 8 | 2 | Amundsen points people to the right table and shows previews and stats where configured; it doesn't answer questions. Data Workers answers across platforms from approved definitions. |
| Data Quality | 8 | 2 | databuilder can load column statistics and badges for display. Data Workers runs checks at the Postgres source and holds Trino tables to baselines the team records. |
| Observability & Incidents | 8.5 | 1.5 | A last-updated timestamp per table, read from Hive or the warehouse. Data Workers detects the break, finds the cause and closes the loop. |
| Pipelines & Ingestion | 8.5 | 1 | databuilder runs as an Airflow DAG to load metadata; Amundsen doesn't change pipelines. Data Workers proposes the DAG or SQL change and queues the rerun behind approval. |
| Schema & Migration | 8 | 3 | Column names, types and descriptions from the Hive Metastore and Postgres extractors, with no change detection. Data Workers detects schema changes at the source and drafts the fix with rollback SQL. |
| Governance & Access | 8.5 | 3 | Owners, tags and badges on each table, with no policy engine. Data Workers routes each change to a named owner and records the approval. |
| Security & Privacy | 8 | 2 | Tags and badges can mark sensitive tables. Data Workers flags sensitive column names in pull request review and dry-runs grants against sensitive columns. |
| Cost / FinOps | 8 | 1 | Usage feeds search ranking, not spend. Data Workers attributes Snowflake spend to the dbt model and drafts the change for its owner. |
| MLOps & Models | 7.5 | 2 | ML features can be indexed with lineage and owners. Data Workers keeps the data under models healthy. |
These are directional scores of scope, not benchmarks, and the reasoning is shown so you can check every line.
How Amundsen and Data Workers work together
Analysts stay in Amundsen's search and engineers in Claude Code or Cursor. Spellbook Data Catalog (in preview) is where the data team looks: each proposed change, the owner it touches, its blast radius, the checks and the rollback. Underneath, Data Context Wizard keeps one governed context graph, the Data-Agents Swarm does the work with more than 20 specialist agents, and the Autonomous Data-Conductor runs each fix end to end (detect, diagnose, fix, review, verify, remember) under per-domain guardrails.
What Data Workers reads, and how. Data Workers connects to Amundsen over its metadata REST API today. The table detail endpoint returns columns, description, owners, frequent users, last-updated time, tags and badges; the lineage and popular-resources endpoints add upstream and downstream tables and what people use most. Context Wizard keeps each fact with its source and time. Underneath, Data Workers connects natively to PostgreSQL and Airflow, and to the Hive Metastore and Trino over their APIs today, so it sees the source schemas and the DAG runs that Amundsen summarizes.
One idea carries straight over. Amundsen ranks by distinct readers, so one heavy user can't push a table to the top. Data Workers' golden-path ranking adapts the same log-dampened formula, credited to Amundsen under its Apache 2.0 license, over the usage it reads from your query history. identify_golden_path and search_across_platforms answer "which table should I use" across every platform.
Every table people find gets a live trust check. monitor_metrics baselines the team records track lateness and the numbers themselves. explain_table returns a table's definition, lineage, documentation and trust score in one call; quality comes from get_quality_score and open incidents from get_incident_history. generate_documentation drafts descriptions for tables Amundsen never had one for. When a fix should change what Amundsen says, Data Workers proposes it for the owner, who edits the description in Amundsen or leaves it. Approved facts land in the Context Wizard graph, where a named person promotes them to authoritative; no agent can promote its own work.
Setup over MCP today. Amundsen has no MCP server, so the client config holds Data Workers' agents only. Clone the open-source repository and add start-agent.sh entries, as the client setup docs show; connections to your Postgres replica and Airflow go in the deployment configuration.
// Example: .mcp.json for Claude Code
{
"mcpServers": {
"dw-context-catalog": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-context-catalog"]
},
"dw-schema": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-schema"]
},
"dw-quality": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-quality"]
},
"dw-incidents": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-incidents"]
}
}
}List the tools with /mcp in Claude Code. Then "is the GMV table right this morning?" gets the new column from the run_quality_check profile, the path from trace_cross_platform_lineage, the reach from blast_radius_analysis and the cause from get_root_cause, in one answer.
One request, L0 to L4. The autonomy ladder is set per domain.
- •L0 manual. An analyst notices the GMV jump and an engineer chases it by hand.
- •L1 observe. Data Workers explains each source change with its path, owner and blast radius, and changes nothing.
- •L2 propose. Data Workers drafts the diff and the check; the owner approves in Spellbook before anything runs.
- •L3 act reversibly. For proven classes, such as rerunning a partition after an approved fix, Data Workers queues the rerun, verifies the result and records the undo step for the owner.
- •L4 autonomous. For a scoped, trusted class in one domain, Data Workers fixes and verifies on its own and posts the receipt for review.
The safety model is in is it safe to let AI agents change production data, and where data and credentials live is in where does our data go. The agents run in your infrastructure: your data stays in your systems, and the hosted Conductor sees workflow metadata only. For how this differs from any catalog, see Data Workers vs a data catalog; teams on other open catalogs follow the same pattern in You're on DataHub and You're on OpenMetadata. For choosing, see Data Workers vs Amundsen and Amundsen alternatives.
What changes for your team
Amundsen teams split their week between keeping the self-hosted stack alive and answering "is this number right?". With Data Workers on top, the second job runs on autopilot at the level you set, and the first gets a planned end date.
- •Incidents. A table people find in Amundsen breaks upstream; it arrives traced to the cause, with the fix drafted for the owner.
- •Data quality. Checks run at the source, and failures turn into fixes the owner approves and Data Workers verifies.
- •Cloud spend. Snowflake spend is traced to the dbt model behind it, with the change drafted for its owner.
- •Access. A request for a table found in search is dry-run for effective privileges, sensitive columns and policy conflicts, with a least-privilege recommendation and an expiry, and the grant goes to its owner.
- •Audits. Every change carries the table, the owner, the diff, the checks and the rollback path (who owns the agents).
- •Migrations. A move off Hive runs in planned waves, with parity checks tracked and the completion gate held for the owner's sign-off (Hive and Glue to Unity Catalog).
Keep Amundsen, or consolidate?
Keep Amundsen if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.
For an archived project, the plan has two phases. First, keep Amundsen running for search while Data Workers reads its metadata, owners and usage into the Context Wizard graph and starts keeping the tables behind it right. Your people's habits don't change that quarter. Second, choose where discovery lives next: Spellbook Data Catalog on top of the Context Wizard graph, where the owners, descriptions and usage you built in Amundsen already sit with their source and date; or DataHub or OpenMetadata, which connect to Data Workers over their APIs or MCP servers today, if your team wants another open catalog. Then retire the Neo4j, Elasticsearch and databuilder stack on a date you pick. If you're weighing building that layer yourselves, read build it ourselves with Claude Code and MCP servers: the connection is the easy part; cross-system context, approvals, verification and rollback are the work.
The case for your CFO
The outcome: the discovery habit your team built on Amundsen keeps paying back, and the numbers people find through it stay right, checked at the source every day.
The risk story is plain. Data Workers reads Amundsen and changes nothing in it. At L1 the agents change nothing anywhere. At L2 every change is proposed with its blast radius and goes to a named owner. At L3 only proven, reversible change classes run without a fresh approval. Every action leaves a receipt: the trigger, the diff, the blast radius, the checks with before and after values, the approver and the undo path. Requests no one answers expire and escalate; they never auto-grant. There is zero migration on day one: Postgres, Airflow, the Hive Metastore, Trino and Amundsen stay where they are.
Why now: with no further releases, the stack under Amundsen only ages from here. A planned move beats one forced by a dependency upgrade. The first win is one domain, read-only, where every table people find gets a live trust check and every source change arrives explained. Your search, review process and permissions stay the same. For the numbers, see the ROI of agentic data operations.
The sentence to repeat upstairs: "Amundsen helped our people find the right table; Data Workers keeps that table right, with an owner approving every fix, and gives us a planned way off an archived project."
Getting started
Start with a pilot. Pick one domain your teams find through Amundsen every day, give Data Workers read access to the Postgres and Airflow behind it, with Amundsen's metadata API in your team's hands, and let it explain every source change in that domain before you turn on the first fix class. Plans and the pilot path are on the pricing page, and the pilot is credited in full against the first year.
FAQ
Is Amundsen really archived? Yes. The README's first line reads "Due to inactivity, this project was archived in September 2026. The contents will remain available for historical purposes," and the LF AI & Data Foundation's project page records the vote to archive it. Every repository in the amundsen-io organization is read-only on GitHub. The code stays available under Apache 2.0, and your running install keeps working.
What was Amundsen's last release? databuilder 7.5.1 on August 14, 2024. The metadata, search and frontend services last released on March 6, 2024 (3.13.0, 4.2.0 and 4.3.0).
Can we keep running Amundsen? Yes, for as long as it serves you. Neo4j, Elasticsearch, Flask and the Python dependencies underneath keep moving while Amundsen doesn't, so patching falls to your team.
How do we get our metadata out of Neo4j? Amundsen connects over its metadata REST API today: your team exports tables, descriptions, owners, tags and badges to Context Wizard as proposals, and Data Workers' own checks rest on the Postgres, Airflow and dbt it reads natively. Context Wizard keeps each fact with its source and date, so owners and descriptions carry straight into Spellbook Data Catalog. If you choose DataHub or OpenMetadata next, it connects over its API or MCP server from day one.
Does Data Workers write to Amundsen? No. When a fix should change a description, Data Workers proposes it for the owner, who edits it in Amundsen if they want to. Approved facts land in the Context Wizard graph.
Who approves changes to our tables? A named owner for each table or domain, usually the person Amundsen lists. Requests reach them in Slack or email and the decision happens in Spellbook. Unanswered requests expire and escalate; they never auto-grant.
Sources
- •Amundsen, GitHub repository and README (archive notice; architecture: frontend, search on Elasticsearch, metadata on Neo4j or Apache Atlas, databuilder, common), https://github.com/amundsen-io/amundsen (checked Oct 3, 2026)
- •Amundsen, commit history (archive notice commit 469c1b77, Sep 10, 2026), https://github.com/amundsen-io/amundsen/commits/main (checked Oct 3, 2026)
- •Amundsen, GitHub releases (databuilder 7.5.1, Aug 14, 2024; metadata 3.13.0, search 4.2.0, frontend 4.3.0, Mar 6, 2024), https://github.com/amundsen-io/amundsen/releases (checked Oct 3, 2026)
- •amundsen-io organization repositories (all 11 archived; last pushes Sep 4 to Sep 11, 2026), GitHub API, https://github.com/amundsen-io (checked Oct 3, 2026)
- •LF AI & Data Foundation, Amundsen project page (contributed by Lyft, July 2020; TAC and Governing Board vote to archive, Sep 2026), https://lfaidata.foundation/projects/amundsen/ (checked Oct 3, 2026)
- •PyPI, amundsen-databuilder (7.5.1, Aug 14, 2024), https://pypi.org/project/amundsen-databuilder/ (checked Oct 3, 2026)
- •Amundsen, metadata service REST endpoints (table detail, description, tags, badges, owners, table and column lineage, popular resources, features), https://github.com/amundsen-io/amundsen/blob/main/metadata/metadata_service/__init__.py (checked Oct 3, 2026)
- •Amundsen, databuilder extractors (Hive Metastore, Postgres, Presto views, Neo4j), https://github.com/amundsen-io/amundsen/tree/main/databuilder/databuilder/extractor (checked Oct 3, 2026)
- •Amundsen repository tree (no business glossary component), https://github.com/amundsen-io/amundsen (checked Oct 3, 2026)
- •Data Workers, Client setup (open-source docs), https://dataworkers.io/opensource-docs/client-setup/ (checked Oct 3, 2026)
- •Data Workers open-source repository (agent and tool registrations), https://github.com/DataWorkersProject/dataworkers-claw-community (checked Oct 3, 2026)