OpenMetadata vs DataHub vs Amundsen: which to choose

OpenMetadata vs DataHub vs Amundsen: which fits your situation

If you are shortlisting open-source catalogs today, Amundsen is not a viable new choice: the project was archived in September 2026 due to inactivity, its repository is read-only, and its last service release was in March 2024. The real decision is between OpenMetadata and DataHub. If you already run Amundsen, treat it as the system you are migrating from, not one of the two candidates.

Choose OpenMetadata if you want a single server backed by a relational database, a search index and Airflow-based metadata ingestion, and you are comfortable running Java 21 services plus those dependencies. Its documented bare metal path, Kubernetes deployment and Docker trial mean the same stack can run in several shapes, which helps teams without a Kubernetes platform. Choose DataHub if your organization already operates Kafka and Kubernetes, and you want metadata changes streamed through GMS and its consumers with the Helm charts and prerequisites chart in your existing cluster. Confirm which runtime, database and search versions your environment supports before you commit to either, because both projects document their own requirements and change them between releases.

Whichever you pick, plan the Amundsen exit as its own project. OpenMetadata documents a connector that reads from Amundsen's Neo4j backend with a read-only account, which gives you a path to bring existing metadata across, but ingestion jobs, search behavior and user accounts will still need checking after cutover. Treat Amundsen as a migration source, and run a short proof of concept against your own sources before you decide.

Which catalog fits which team

This table maps common team situations to the catalog most likely to fit, with the reason and the point to confirm in planning. Read it as a starting shortlist, since the right answer depends on your existing Kafka, Kubernetes, Airflow and database footprint. The main takeaway: OpenMetadata is the more natural Amundsen successor for teams that want a single server and relational storage, while DataHub suits teams already operating Kafka at scale.

Team situation	Best fit	Why and what to confirm
Running Amundsen today and needing a migration path	OpenMetadata	OpenMetadata documents an Amundsen connector that reads from Amundsen's Neo4j backend over a read-only Bolt account. Confirm tag and owner mapping, since owners only carry over when emails match OpenMetadata users.
Already running Kafka and Kubernetes at scale	DataHub	DataHub's design centers on Kafka streaming of metadata changes and is deployed with Helm charts. Confirm you can operate the GMS, consumers, Neo4j or Elasticsearch graph index and Kafka as one stack.
Want Airflow-driven ingestion on a single server with a relational database	OpenMetadata	OpenMetadata needs Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, search, and Airflow for ingestion. Confirm your Airflow version, since OpenMetadata 2.0 ships with Apache Airflow 3.3.0 for ingestion.
Need a managed vendor option	DataHub or OpenMetadata, depending on hosting	DataHub Cloud is the managed option from DataHub's maker, and Collate is the managed service from OpenMetadata's maintainers. Compare SLA terms, deployment models and data residency in writing before deciding.
Need broad connector coverage across warehouses, BI and ML tools	Either, after a connector test	OpenMetadata lists more than 130 connectors and DataHub lists more than 150 integrations in its README. Test your specific sources, since counts do not show depth for your stack.
Governance-heavy team needing glossary, quality and lineage in one tool	Either, after a feature check	Both list column-level lineage, glossaries and data quality features. Confirm how each handles your lineage sources and assertion workflows before choosing.
Amundsen still in use for historical reference or read-only lookup	Amundsen (archived)	Amundsen is archived and its repository is read-only, with no service release since March 2024. Keep it only as a read-only reference while you migrate, not as a candidate for new deployments.

Why Amundsen is no longer a safe new choice

Do not start a new Amundsen deployment. The project's README states that it was archived in September 2026 due to inactivity, and the amundsen-io/amundsen GitHub repository is now read-only. Its contents remain available for historical reference, but no one is obligated to review issues, merge fixes or publish new code. The last service releases were frontend 4.3.0, metadata 3.13.0 and search 4.2.0, all on March 6, 2024, and the last databuilder release was 7.5.1 on August 14, 2024. Read the repository and Amundsen releases page yourself before you rely on that timeline, since the status of a read-only project can change.

The practical risk sits in three places. First, security patches: if a vulnerability is found in the frontend, metadata or search service, or in a dependency they pull in, nobody upstream is positioned to ship a fix, so your team would carry the patch burden alone. Second, runtime upgrades: the README lists Python 3.8 or later and Node v12 as requirements, and both runtimes move on their own schedules. Your security team will eventually need to move the frontend, databuilder jobs and any Airflow DAGs that import databuilder onto supported versions, and an archived codebase gives you no maintainer to confirm that the combination still works. Third, the Neo4j or Apache Atlas persistence layer and the Elasticsearch search service carry their own lifecycles that you must track separately.

Treat the archive as a reason to plan a migration, not a reason to freeze the current system. Inventory every Amundsen component, including the Neo4j or Atlas backend, any Neptune or relational variants, and every databuilder job, then record which runtimes and images each one needs. Ask your security team to define how long an unpatched Amundsen component may stay in production. For the migration path, OpenMetadata's documented Amundsen connector reads metadata from the Neo4j backend with a read-only account, which gives you a way to bring existing metadata across while you test a replacement. Confirm the connector's coverage against your own catalog before you commit to it.

Architecture, ingestion and governance side by side

This table sets OpenMetadata, DataHub and Amundsen against the same architecture, ingestion, lineage and maintenance questions. Read the rows that match your environment first, then confirm the gaps marked for vendor confirmation before you shortlist. Amundsen's archived status is the decisive difference for most teams.

Dimension	OpenMetadata	DataHub	Amundsen
License	Apache-2.0, maintained by Collate with commercial enterprise options	Apache-2.0, with DataHub Cloud sold separately by the same company	Apache-2.0, hosted by the LF AI and Data Foundation
Latest supplied release line	2.0 line; 2.0.5 released October 8, 2026	v1.6.0.3 released September 25, 2026; v1.8.0 release candidates followed in October 2026	Archived September 2026; last service releases March 6, 2024, last databuilder release August 14, 2024
Core services and storage	Java 21 server with MySQL 8.0.42+ or PostgreSQL 15+ as the metadata store	Metadata service (GMS) with MySQL or PostgreSQL storage, plus Kafka for streaming metadata changes	Frontend, search and metadata services; metadata persisted in Neo4j or Apache Atlas
Search dependency	Elasticsearch 9.x or OpenSearch 3.x	Elasticsearch or OpenSearch	Elasticsearch
Ingestion model	Metadata ingestion runs on Airflow, with connectors for more than 130 sources	Both push and pull ingestion, with more than 150 integrations listed in the README	databuilder library, loaded by a Python script or an Airflow DAG
Lineage depth	Table, column, dashboard, pipeline and metric lineage with OpenLineage event integration	Column-level lineage	Not covered by supplied facts; confirm with the Amundsen project before relying on it
Glossary, quality and governance	Glossaries, classifications, domains, data quality tests, profiling and freshness checks	Business glossary, data profiling, ownership and usage, and data quality assertions and monitoring	Usage-based search ranking; confirm glossary and quality features against the archived codebase
API and SDK options	REST APIs, Python SDK, TypeScript packages and Java libraries	Confirm the current API and SDK surface with the vendor's documentation	Confirm programmatic access in the archived repository
Maintenance status	Active: maintenance releases 2.0.1 to 2.0.5 followed 2.0.0 on August 24, 2026	Active release line with a 1.8 cycle in progress	Read-only archived repository; no security or service fixes expected from the project

Licensing and editions for each catalog

OpenMetadata is released under the Apache License 2.0 and is maintained by Collate, which also offers commercial enterprise capabilities and premium support. The open-source project is the same codebase you can self-host in your own infrastructure, and the commercial layer sits on top of it rather than replacing it. Your licensing exposure for the open-source core is therefore limited to Apache-2.0 terms, while any paid capability comes from a separate agreement with Collate.

Open-source core: The Apache-2.0 release covers the catalog, its connectors, lineage, data quality and governance features listed in the project documentation.
Maintainer-led paid tier: Collate sells enterprise capabilities and premium support. Ask which features sit in each tier and whether any of them are required for your use case.
Support path: Self-hosted teams without a Collate contract rely on community channels and their own staff or implementation partner for upgrades.
Release cadence: Confirm the support window for the release line you plan to run, since 2.0 is the current line and maintenance releases follow regularly.
Breaking changes: Review the 2.0 migration notes before upgrading, because some changes affect credentials and ingestion images.

Before signing, confirm in writing which capabilities are paid, what Collate's support terms cover and whether any feature you depend on is available only under a commercial agreement.

How release activity affects your upgrade plan

The first thing to plan for is that OpenMetadata and DataHub both ship often, and each upgrade path carries different work. OpenMetadata 2.0.0 was released on August 24, 2026, and maintenance releases followed, through 2.0.5 on October 8, 2026, at roughly one to two week intervals. Its 2.0 release notes list breaking changes you must handle before upgrading: embedding credentials moved into an llmConfiguration block, a new Databricks auth format, custom ingestion images rebuilt for Python 3.12 (with Apache Airflow 3.3.0), and a migration to Great Expectations 1.3 before the upgrade. Inventory every ingestion job, custom image and Databricks connection now, because those are the places where a 2.0 upgrade breaks first. Read the OpenMetadata 2.0 release notes in full before choosing a target patch level.

DataHub's most recent tagged release in the supplied record is v1.6.0.3, released on September 25, 2026, and v1.8.0 release candidates followed in October 2026. Your plan should cover how that line is adopted, not which one is safer. On Kubernetes, the Helm chart runs a system-update job on upgrades that applies schema changes and reindexes search indices when needed. Confirm that the job completes in a staging cluster sized like production, since search reindexing time grows with metadata volume, and confirm your Elasticsearch or OpenSearch and Kafka versions against the chart's requirements before you change anything. Ask DataHub or your DeployOpen team to document the rollback path for a failed system-update job.

Amundsen adds no upgrade work in the usual sense, because its last service releases date from March 6, 2024 and its last databuilder release from August 14, 2024, and the repository was archived in September 2026. The real planning question is how often you will need to take a security fix that nobody upstream will publish. Whichever catalog you choose, set a standing review of release notes, subscribe to the GitHub release feeds, and budget the staging test cycle for each patch so that a security update can move through your change process in days rather than weeks.

What drives the running cost of each catalog

Each catalog costs more to run than its license suggests, because the software needs supporting services that you host, patch and size. The cards below separate the self-hosted footprint of OpenMetadata and DataHub, the legacy burden of Amundsen, and the point where a vendor tier replaces that work. Ask every vendor for the same breakdown before comparing totals.

OpenMetadata service dependencies

A production OpenMetadata install needs a database, a search service and an ingestion orchestrator alongside the server. The documented bare metal minimum is 2 vCPUs, 4 GB RAM and 20 GB storage for the server, and at least 2 vCPUs, 2 GB RAM and 30 GB storage for each of the database and search services. Ingestion runs on Airflow, so the Airflow stack is a fourth component you size and upgrade. Ask whether your quote includes ingestion workers and how many sources you plan to scan.

DataHub streaming and graph footprint

DataHub runs GMS, the MAE and MCE consumers and the frontend, and it depends on Kafka, a relational database, Elasticsearch or OpenSearch, and a graph index on Neo4j or Elasticsearch. The Kubernetes guide notes that more than 7 GB of RAM is needed to run DataHub and its dependencies on Minikube, which is a local trial, not a production sizing. Kafka is often the largest recurring item because it must be operated, monitored and kept upgraded. Confirm who owns Kafka and whether it is shared with other teams.

Amundsen legacy and unpatched risk

Amundsen was archived in September 2026, and its last service releases date from March 2024 with the last databuilder release in August 2024. Running it means carrying Neo4j or Apache Atlas, Elasticsearch, Python and Node runtimes and Airflow DAGs with no upstream fixes. Any security patch becomes your team's work, and the cost grows each month the platform stays in place. Price that exposure into the migration case, not just the current hosting bill.

Vendor tiers versus self-hosting

Each project has a commercial owner that sells a managed or enterprise option, such as Collate for OpenMetadata and DataHub Cloud for DataHub. A managed tier moves hosting, upgrades and uptime commitments to the vendor and typically bills per user, asset or tier. Self-hosting shifts that cost to your staff and your cloud accounts. Ask each vendor for the tier limits, included support hours, the uptime commitment in writing and the exit path if you leave.

How a cutover from Amundsen usually proceeds

The sequence moves an archived Amundsen catalog into OpenMetadata in a controlled order, so that lineage, ownership and search are verified before any team stops using the old system.

Inventory Amundsen's metadata sources and jobs
Your platform or data engineering team lists where Amundsen's metadata lives, whether in a Neo4j graph or an Apache Atlas deployment, and which databuilder jobs and Airflow DAGs load it. Record the Elasticsearch search index, the frontend and metadata services, and any amundsengremlin or amundsenrds loaders in use. The output is a written inventory that names each source system, each scheduled job and its owner, so nothing feeding Amundsen is missed when it is retired.
Confirm connector coverage for each source
Before building anything, check which of these sources OpenMetadata's Amundsen connector can read. The documented connector reads Amundsen's Neo4j backend over a Bolt URI. If your metadata sits in Atlas, Neptune or a relational store, that path is different and must be planned separately, with the vendor docs and your own environment as the source of truth. The output is a short coverage table marking each source as covered, needs a custom route, or is out of scope.
Connect with a read-only Bolt account
A database administrator creates a read-only account on the Neo4j instance that backs Amundsen and provides the Bolt URI to the OpenMetadata team. The account should be unable to write to the graph, so the migration cannot alter the catalog the legacy services still depend on. The output is a successful test connection from the OpenMetadata ingestion environment using only that account, with the connection details stored in your secrets manager.
Verify tag inclusion and owner matching
Run a first metadata ingestion into a non-production OpenMetadata instance and review the results against Amundsen. Per the connector documentation, tags are included by default, while owners are assigned only when the source owner's email matches a user already present in OpenMetadata. Sample a set of tables from each domain and count how many have owners after ingestion. The output is a list of unmatched owners that data stewards resolve by creating users or correcting source emails before production runs.
Rebuild search and user access
Set up OpenMetadata's search backend, Elasticsearch 9.x or OpenSearch 3.x, and map identity so that users sign in through your identity provider. Confirm that search returns expected assets, that ownership and domain filters work, and that teams who used Amundsen's usage-based ranking understand how results now appear. The output is a sign-off from a sample group of users who test common discovery tasks on the new catalog, with access rights checked against your existing groups.
Move ingestion schedules and lineage sources
Replace the databuilder jobs and Airflow DAGs that fed Amundsen with OpenMetadata ingestion workflows, scheduled on the orchestrator you run for ingestion. Check which lineage sources feed OpenMetadata, including OpenLineage events where your pipelines emit them, so lineage is not lost in the move. The output is a run history showing each workflow completing on schedule for a full cycle, with a recorded list of any lineage gaps compared with the Amundsen baseline.
Run both catalogs in parallel
Keep Amundsen read-only and running while teams search in OpenMetadata for an agreed period, so that users can compare results and report missing assets, owners or tags. Track the questions raised and close each one by fixing the connector mapping, the source metadata or the user record. The output is a closed issue log and a confirmed set of discovery workflows that work in OpenMetadata without Amundsen.
Retire Amundsen and keep an archive
Once the parallel run closes cleanly, stop the Amundsen services, databuilder jobs and DAGs, and disable scheduled loads. Export or snapshot the Neo4j graph and the Elasticsearch index so the historical metadata stays available for audit, since the Amundsen README notes its contents remain for historical purposes. The output is a decommissioning record that lists stopped components, the archive location and the date each team confirmed the cutover.

What implementing each catalog involves

The heaviest OpenMetadata work falls to the platform team, and the first decision is the deployment target. Docker suits a trial, while production runs on Kubernetes (EKS, AKS, GKE or an on-premises cluster) or on bare metal. Either way, the team must provide Java 21, a MySQL 8.0.42 or later or PostgreSQL 15 or later database, and Elasticsearch 9.x or OpenSearch 3.x for search. The published minimums (2 vCPUs, 4 GB RAM and 20 GB storage for the server, with the database and search services each needing at least 2 vCPUs, 2 GB RAM and 30 GB storage) are a starting point for sizing. Data engineers own the ingestion pipelines that run on Airflow and their schedules, and the identity team configures SSO using the settings in OpenMetadata's security documentation.

DataHub's install is a Kubernetes project before it is a catalog. The platform team deploys the Helm charts from the acryldata/datahub-helm repository together with the separate prerequisites chart for Kafka, the relational database, Elasticsearch and the graph index, and sizes them as one system. The DataHub guide says more than 7 GB of RAM is needed to run DataHub and its dependencies on Minikube, so production capacity needs more headroom. Kafka deserves its own operating plan, since the GMS service, the MAE and MCE consumers and the frontend all depend on it. On self-deployed DataHub Core, the identity team's OIDC provider must be configured on the frontend by the operator, while DataHub Cloud handles this through its interface. Schedule each upgrade with the system-update job in mind, because the chart runs it to apply schema changes and reindex search when needed. The DataHub Kubernetes guide sets out these components.

Amundsen's work is mostly migration and retirement. Its last service releases date from March 2024 and its databuilder from August 2024, and the project was archived in September 2026, so the team carries any future fix to the stack. Data engineers must map each databuilder job, whether a Python script or an Airflow DAG, to a replacement ingestion pipeline. The platform team should plan a read-only Bolt connection to the Neo4j backend for the OpenMetadata Amundsen connector, and confirm that Neo4j is the backend in use before cutover. The identity team should review owner matching early, since owners carry over only when the source owner's email matches an OpenMetadata user, and unmatched owners will need manual cleanup. Amundsen's README lists Python 3.8 and Node v12 as requirements, which should be verified against current runtimes before any reuse of its tooling.

Questions buyers ask before hiring help with a catalog

Which open-source catalog should replace Amundsen?

For most teams, OpenMetadata is the closer fit if you want discovery, lineage, data quality, glossaries and governance in one product. DataHub suits teams that already run Kafka and want metadata changes streamed as events. Amundsen's last service release was on March 6, 2024, and the project was archived in September 2026, so either option is a migration project. OpenMetadata documents a connector that reads Amundsen's Neo4j backend over a Bolt URI with a read-only account, which can carry tags and owners into the new catalog during cutover. Owners are assigned only when the source owner's email matches an OpenMetadata user, so review identity mapping before you start. Test both tools against a sample of your own sources before you decide.

How much effort does each catalog take to run?

Effort rises with the number of stateful services you operate yourself. OpenMetadata needs Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, Elasticsearch 9.x or OpenSearch 3.x for search, and Airflow for running ingestion. Its documented minimums are 2 vCPUs, 4 GB RAM and 20 GB storage for the server, with the database and search services each needing at least 2 vCPUs, 2 GB RAM and 30 GB storage.

DataHub adds Kafka and a graph index on Neo4j or Elasticsearch to its database and search tier.
The DataHub Kubernetes guide says more than 7 GB of RAM is needed to run DataHub and its dependencies on Minikube.
Amundsen's services depend on Neo4j or Apache Atlas, and its releases date from 2024, so it adds maintenance risk on top of migration work.

Upgrade effort also varies. DataHub's Helm chart runs a system-update job during upgrades to apply schema changes and reindex search when needed.

Can our team implement a catalog without outside help?

Yes, if you already have platform engineers who run Kubernetes or bare metal, data engineers who own ingestion, and someone who can configure OIDC single sign-on. The work becomes harder when those skills are split across teams or when the catalog must fit a regulated change process. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing upgrades and support are available as retainers. Ask us to show how the written scope maps to your sources, identity setup and environments.

How long does a catalog rollout take?

No rollout duration is supplied for this comparison, so no timeline is stated here. The scope agreed in writing sets timing. The main drivers are the number of sources and connectors, how many environments you run, whether you migrate Amundsen history or only current metadata, and how many identity and role mappings you configure. Ask any provider for milestones tied to each of those items, and ask which steps depend on your team's approvals. Plan upgrade work as recurring. OpenMetadata 2.0 maintenance releases have followed about every one to two weeks, and DataHub upgrades can trigger schema changes and search reindexing.

What does a catalog project need from data engineers and the identity team?

Data engineers own connectors, scheduled ingestion, lineage checks and the quality tests that make metadata trustworthy. OpenMetadata 2.0 lists breaking changes that affect them, including moving embedding credentials into an llmConfiguration block, a new Databricks auth format, rebuilding custom ingestion images for Python 3.12, and migrating Great Expectations to 1.3 before upgrading. The identity team owns single sign-on and role mapping. DataHub supports OpenID Connect providers such as Google, Okta and Azure AD, and on self-deployed DataHub Core the frontend must be configured by the operator. Confirm the authentication and access model in the OpenMetadata security documentation before you finalize roles.

Does Airflow have to be in place for OpenMetadata ingestion?

The bare metal prerequisites list Airflow as the component that runs metadata ingestion, so plan for it unless your chosen deployment path documents another method. Confirm that choice with the deployment documentation before you commit. Airflow's version matters. Airflow 2 reached end of life on April 22, 2026, Airflow 3.3.2 is the current release, and OpenMetadata 2.0 moved its ingestion images to Airflow 3.3.0. If you already run Airflow 2, include that upgrade in the project. DataHub's architecture summary describes push and pull ingestion and does not list Airflow among its core components, so its ingestion design differs.

Which catalog offers deeper lineage and governance features?

Both cover the core needs, so the answer depends on which features your governance program uses. OpenMetadata lists table, column, dashboard, pipeline and metric lineage with OpenLineage event integration, plus data quality tests, profiling, freshness checks, glossaries, classifications and domains. DataHub lists column-level lineage, a business glossary, profiling of schema, statistics, ownership and usage, and data quality assertions and monitoring. Map your required lineage types, glossary workflow and quality checks against each product in a proof of concept. Catalog features can support evidence collection for compliance work, but a catalog does not establish compliance on its own, and independent auditors and certification bodies issue audit reports and certifications.

Five things to confirm before you commit

Each catalog's documentation describes its architecture, but your warehouses, search stack, and orchestrator decide how well it fits. The checks below cover what the vendor docs leave to your environment, and each one is worth settling in writing before a migration plan starts.

Lineage depth for your warehouses

Lineage support varies by connector, source and lineage type, so a catalog can list a warehouse without tracing column-level dependencies inside it. Ask for a proof of concept against your own warehouse and a sample of your dbt models, pipelines and dashboards. Check whether table, column, dashboard and pipeline lineage all appear for the sources your analysts actually query. Record any gaps before you compare the three catalogs.

SSO and role model in your edition

DataHub's OIDC setup differs between self-deployed DataHub Core, where the operator configures the frontend, and DataHub Cloud, where the interface handles it. Confirm which identity providers, group mappings and roles each option supports for your team. Also confirm which access controls OpenMetadata and Amundsen offer in the edition you plan to run. Treat SSO and role design as a requirement to test, not a checkbox.

Search engine version support

OpenMetadata's bare metal prerequisites name Elasticsearch 9.x or OpenSearch 3.x, while DataHub and Amundsen each depend on search in their own way. If your organization already runs a search cluster, confirm that its version falls within each product's supported range. Ask whether the vendor will certify your exact distribution and version before you size the cluster.

Airflow alignment with OpenMetadata 2.0

OpenMetadata runs metadata ingestion through Airflow, and its 2.0 ingestion images moved to Airflow 3.3.0 on Python 3.12. Airflow 2 reached end of life on April 22, 2026, so an existing Airflow 2 estate will need a planned upgrade or a separate ingestion environment. Confirm which Airflow version your ingestion will use and whether your custom ingestion images need rebuilding. DataHub and Amundsen use Airflow differently, so map each option to your scheduler.

Support window for the release line

OpenMetadata 2.0.x and DataHub's v1.x line are both active, but maintainers do not publish a fixed support window in the facts used here. Ask each vendor for its support and security patch policy for the release line you will deploy, and for the upgrade path to the next major line. Amundsen is archived and receives no new service releases, so plan for it to be a source of migration data only. Put the answers in your contract or statement of work.

How DeployOpen helps choose and implement a data catalog

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a catalog decision, that means helping you test OpenMetadata and DataHub against your own sources and dependencies before you commit, and carrying the chosen catalog through to a documented, supported production install.

How we scope

We agree the catalog candidates, source systems, lineage depth and governance requirements in writing before any work starts.
We inventory existing Amundsen, Airflow and database dependencies so the cutover path and its ingestion jobs are visible up front.
Engagements are fixed-scope, with deliverables and timelines agreed in writing. A quote follows from that written scope.

How we build

We stand up the chosen catalog in your environment with the database, search and ingestion components its architecture requires.
We configure connectors, SSO and role access, and test lineage and search results against sources you choose to validate.
We run security hardening and testing on the deployment, including review of its exposed interfaces and access paths.

How we hand over

We document the deployment, ingestion schedules, upgrade steps and the dependencies your team must keep patched.
We prepare the controls and evidence your compliance assessors may ask for, without issuing any audit report or certification.
We walk your engineers through day-to-day operation so the catalog is run by your own team after handover.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, sized to the catalog's release cadence.
We plan upgrades against the vendor's breaking-change notes, including ingestion image and dependency version changes.
We can also support the Amundsen retirement, keeping historical metadata and access records available as your team needs them.

OpenMetadata vs DataHub vs Amundsen