Which open-source data catalog fits your team
Choose OpenMetadata or DataHub if your estate is built around cloud warehouses, BI tools and modern pipelines, and choose Apache Atlas if your governance is centered on Hadoop. All three are licensed under Apache-2.0, so the license will not separate them. Do not shortlist *Amundsen* for new work, because it was archived in September 2026 and adopting it now means building on a project whose public repository no longer takes development. Your first filter is the estate, not the license. A team with Hive, HBase and Kafka at the core of its data platform should test Atlas first, while a team with Snowflake, BigQuery, dbt or Tableau should test the other two.
Commercial support differs by vendor. Collate maintains OpenMetadata and sells enterprise capabilities and premium support alongside the Apache-2.0 release, while Acryl sells DataHub Cloud, which the DataHub README describes as managed and SLA-backed with no infrastructure to run. Apache Atlas is an Apache Software Foundation project, and the facts available to us do not name a commercial vendor for it, so confirm with your own integrator who would support it. Self-hosting any of the three carries no license fee under Apache-2.0, so the recurring costs are the staff who run the search, graph and streaming dependencies, plus upgrades and connector maintenance. Ask every bidder to price installation, connector build-out, SSO configuration, upgrades and ongoing support as separate line items in a written scope.
Infrastructure is where the three diverge most. OpenMetadata's bare metal prerequisites call for Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x, and ingestion runs on Airflow. DataHub needs Kafka for streaming metadata changes, a MySQL or PostgreSQL database and Elasticsearch or OpenSearch, and its Kubernetes guide deploys it with Helm charts. Atlas stores metadata in JanusGraph, with HBase and Solr in its documented setups. Before you commit, confirm the Java and search versions against the installation docs for the release you will deploy, and check whether your platform team already runs Kafka, Kubernetes or HBase, since that changes the effort more than the license does.
How to match each catalog to your situation
This fit suits teams whose data mostly lives in cloud or on-premises warehouses and is consumed through BI tools. OpenMetadata and DataHub both list broad connector sets for warehouses, BI tools, pipelines and ML platforms, and both cover table and column lineage. Either can be the right answer here, and the deciding factors are usually the stack you run and the infrastructure you are prepared to operate.
- OpenMetadata fits teams that want one platform for discovery, quality and governance. It bundles profiling, data quality tests, glossaries and domains, and it needs Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, plus Elasticsearch 9.x or OpenSearch 3.x.
- DataHub fits teams that want a metadata graph fed by streaming changes. Its GMS and Kafka architecture suits high change volumes, and its README lists more than 150 integrations, including Snowflake, BigQuery, Databricks, dbt, Looker and Tableau.
- Check connector coverage against your exact versions. Confirm each connector for your warehouse, BI tool and orchestrator before you commit.
- Plan for the search and database tier. Both platforms need a supported relational database and a search cluster, which adds components to back up and upgrade.
Before choosing, run a proof of concept against your largest warehouse and confirm lineage depth, permission model and upgrade process on your own infrastructure.
Apache Atlas was built as governance services for Hadoop and is the only one of the three with a documented hook model for Hadoop-era tools. It ships hooks for Hive, HBase, Kafka, Sqoop, Storm, Falcon and Couchbase, and it pairs with Apache Ranger for runtime access control. If your estate is built around Hive metastore lineage and Ranger policies, Atlas is the natural first evaluation, though the operating footprint is a substantial consideration.
- Atlas wins when Hive and Ranger are already the control plane. Its type system and REST API let you extend governance models you already run.
- Atlas carries a heavier storage stack. Its documented setups use JanusGraph with Apache HBase and Apache Solr, and BerkeleyDB is the alternative setup.
- Atlas uses Java 8, 11 or 17 builds. Confirm which Java version your hosts and security baseline support before you plan upgrades.
- Release cadence needs checking. The downloads page lists 2.5.0 on April 30, 2026, after 2.4.0 on January 2, 2025, so confirm the support position of the line you intend to run.
- Atlas does not win if most data sits outside Hadoop. Teams with mainly cloud warehouses often find OpenMetadata or DataHub simpler to operate.
Before deciding, confirm with the Atlas community and your own platform team how each hook behaves on your Hadoop distribution version.
A managed service moves part of the operating load to a vendor, but it changes where your metadata lives and how you pay. DataHub's README describes DataHub Cloud as managed, SLA-backed and enterprise-ready with no infrastructure to run. OpenMetadata is maintained by Collate, which offers commercial enterprise capabilities and premium support. Atlas is an Apache Software Foundation project, so a managed option depends on third-party providers.
- DataHub Cloud removes the most infrastructure from your team. You still pay for connectors, integration work and internal ownership of metadata.
- Collate offers OpenMetadata commercial capabilities and support. Ask which features are in the open-source build and which are in the commercial tier.
- Atlas managed options depend on third parties. Confirm with each provider which versions and integrations they support.
- Self-hosting still needs an owner. Managed services reduce upgrades and scaling work but not access reviews, data classification and connector maintenance.
- DeployOpen supports self-hosted deployments. It offers ongoing support as retainers, which is a different arrangement from a vendor-operated SaaS.
Ask each vendor for the written data residency terms, SLA scope and exit process before you compare prices.
Which catalog for which scenario
This table matches common team situations to the catalog whose connectors, required components and hosting model fit them best. Read each row for the reason, then check the named requirement against your own estate. The main takeaway is that connector breadth, Hadoop lineage and Kubernetes packaging point to different catalogs, and the components each one needs usually shape the effort more than the feature list does.
| Scenario | Best fit | Reason and what to confirm |
|---|---|---|
| Modern warehouse estate with many BI tools | OpenMetadata or DataHub | OpenMetadata lists more than 130 connectors and DataHub lists more than 150 integrations, including Snowflake, BigQuery, Databricks, dbt, Looker and Tableau. Confirm that your specific warehouses and BI tools appear in the connector list for the version you plan to run. |
| Hadoop and Hive governance | Apache Atlas | Atlas documents hooks for Hive, HBase, Kafka and Sqoop, stores metadata in JanusGraph on HBase with Solr indexing, and pairs role-based and attribute-based security with Apache Ranger. Expect to operate that Hadoop-era stack alongside the catalog. |
| Kubernetes-first platform team | OpenMetadata or DataHub on Helm | OpenMetadata documents production deployments on EKS, AKS, GKE and on-premises clusters. DataHub uses Helm charts with a separate prerequisites chart and a system-update job on upgrades. Both need database and search services planned up front, and DataHub also needs Kafka. |
| Small team wanting minimal moving parts | Trial in Docker before committing | The DataHub Docker quickstart requires 8 GB of RAM and Python 3.10 or later. OpenMetadata bare metal needs Java 21, a database, Elasticsearch or OpenSearch, and Airflow for ingestion. Count the components you would operate before choosing, and ask whether an existing Airflow estate can host ingestion. |
| Buyer wanting a vendor-managed option | DataHub Cloud or Collate-supported OpenMetadata | DataHub Cloud is described in the DataHub README as managed with no infrastructure to run. Collate maintains OpenMetadata and offers commercial capabilities and premium support. Apache Atlas has no managed service in the supplied facts, so confirm options with a provider and get any SLA in writing. |
How OpenMetadata, DataHub and Atlas store and index metadata
Each catalog pairs a relational or graph store with a search index, and the components you must run follow from that pairing. OpenMetadata's bare metal deployment docs call for Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later for the database, and Elasticsearch 9.x or OpenSearch 3.x for search. Metadata ingestion runs on Airflow. DataHub centers on a metadata service (GMS) that streams metadata changes through Kafka, stores records in MySQL or PostgreSQL, and indexes them in Elasticsearch or OpenSearch. Its Kubernetes guide adds the MAE Consumer and MCE Consumer, plus a graph index on Neo4j or Elasticsearch. Confirm which graph index your team will operate before sizing, because that choice changes what you patch, back up and monitor.
Atlas uses a different model. Its type system defines types and entities that hold technical and business metadata and the relationships between them. Metadata persists in *JanusGraph*, the only graph implementation available, with Apache HBase as the storage backend and Apache Solr for indexing in the documented setups, and a BerkeleyDB setup is also documented in the Atlas installation instructions. Integration runs through a REST API and a Kafka-based messaging interface, where hooks for Hive, HBase, Kafka, Sqoop, Storm, Falcon and Couchbase publish metadata and consumers receive change events. Atlas builds with Java 8, 11 or 17. Whether that stack suits you depends mostly on whether your team already runs HBase, Solr and Kafka in production.
Capability and infrastructure side by side
This table compares OpenMetadata, DataHub and Apache Atlas on license, release activity, connectors, lineage, governance, access, APIs, storage and deployment. Read the infrastructure rows closely, since the search, database and runtime prerequisites drive most of the operating work. Items marked to confirm were not verified in our sources, so check them with the vendor or in a test environment before you decide.
| Capability | OpenMetadata | DataHub | Apache Atlas |
|---|---|---|---|
| License and commercial vendor | Apache-2.0. Collate maintains it and sells enterprise capabilities and premium support. | Apache-2.0. The maker sells DataHub Cloud, a managed, SLA-backed option. | Apache-2.0 Apache Software Foundation project. No commercial vendor fact supplied; confirm with distributors. |
| Latest release line and date | 2.0.5 on October 8, 2026, after 2.0.0 on August 24, 2026. | v1.6.0.3 on September 25, 2026, with v1.8.0 release candidates in October 2026. | 2.5.0 on April 30, 2026; 2.4.0 on January 2, 2025; 2.3.0 on December 6, 2022. The 2.6.0 entries are release candidate tags, not final releases. |
| Connectors | More than 130 connectors for warehouses, BI tools, pipelines and ML platforms. | More than 150 integrations, including Snowflake, BigQuery, Databricks, dbt, Looker and Tableau. | Documented hooks for Hive, HBase, Kafka, Sqoop, Storm, Falcon and Couchbase. Confirm other sources. |
| Lineage, quality and profiling | Table, column, dashboard, pipeline and metric lineage via OpenLineage, plus data quality tests, profiling and freshness checks. | Column-level lineage, schema and usage profiling, and data quality assertions with monitoring. | Type-based metadata relationships are documented. Lineage and quality coverage: confirm with the vendor. |
| Governance features | Glossaries, classifications and domains. Context Center added in 2.0. | Business glossary and ownership metadata. Confirm fine-grained policy support in your edition. | Technical and business metadata in a type system. Role- and attribute-based security via Apache Ranger. |
| SSO approach | Confirm supported identity providers and configuration steps in the security documentation. | OpenID Connect providers such as Google, Okta and Azure AD. Self-deployed Core needs operator configuration. | Not covered in our sources. Confirm authentication options and how they pair with Ranger. |
| APIs and SDKs | REST APIs, a Python SDK, TypeScript packages and Java libraries. | Confirm the current SDK and API list in the DataHub documentation. | REST API for all functions, plus a Kafka-based interface for hooks and change events. |
| Search and storage requirements | Java 21, MySQL 8.0.42+ or PostgreSQL 15+, Elasticsearch 9.x or OpenSearch 3.x, and Airflow for ingestion. | Kafka, MySQL, PostgreSQL or MariaDB, Elasticsearch or OpenSearch, and a graph index on Neo4j or Elasticsearch. | JanusGraph with HBase storage and Solr indexing in documented setups; BerkeleyDB as an alternative. Builds on Java 8, 11 or 17. |
| Kubernetes and bare metal | Kubernetes on EKS, AKS, GKE or on-premises, and bare metal. Minimum server: 2 vCPUs, 4 GB RAM, 20 GB storage. | Kubernetes through Helm charts plus a prerequisites chart. Docker quickstart needs 8 GB RAM. | Installation docs cover self-managed setups. Confirm supported container or Kubernetes packaging with the project. |
Each catalog in brief, with its license
Four catalogs appear on most shortlists, and they differ more in operating model than in license. Three are Apache-2.0 projects with active release lines, and one is archived and should not receive new deployments. Each card names the condition under which that option is the right pick, along with the component or check that decides it.
OpenMetadata for a single governance platform
Choose OpenMetadata when you want one Apache-2.0 catalog covering discovery, lineage, data quality and governance, and you can run its stack: Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, Elasticsearch 9.x or OpenSearch 3.x, and Airflow for metadata ingestion. Collate maintains the project and sells commercial enterprise capabilities and premium support, so list the features you need and check which edition provides them. Review the 2.0 breaking changes before upgrading.
DataHub for broad connector coverage
Choose DataHub when connector breadth and column-level lineage matter more than a small footprint. The architecture centers on a GMS service with Kafka, MySQL or PostgreSQL, and Elasticsearch or OpenSearch, so your team must run streaming and search infrastructure. Its README lists more than 150 integrations. DataHub Cloud comes from the same company as a managed, SLA-backed option, so compare the staffing cost of Core against that subscription. On Core, the operator configures OIDC single sign-on on the frontend.
Apache Atlas for Hadoop-centric estates
Choose Apache Atlas when your platform is built on Hadoop and its ecosystem, and hooks for Hive, HBase and Kafka are central to your design. Atlas stores metadata in JanusGraph, with HBase and Solr in its documented setups, so your team needs experience with those systems. Its REST API and Kafka messaging connect hooks and consumers, and its README pairs access control with Apache Ranger. Confirm that Java 8, 11 or 17 and the storage stack fit your platform, and check the newest tagged release before you plan.
Amundsen as a legacy catalog
Do not start new work on Amundsen. It was archived in September 2026, and archived repositories typically stop accepting changes. Teams already running it should map what their users depend on, then plan a move to an active catalog while the current deployment still works. Confirm the archive status and any remaining support terms directly with the project before you make that plan, since your own compliance evidence may depend on them.
What the open-source license covers and what the paid tiers add
All three named catalogs, OpenMetadata, DataHub and Apache Atlas, are licensed under Apache-2.0, an OSI-approved license that lets you run, modify and redistribute the code without a license fee. That license covers the source code only. OpenMetadata is maintained by Collate, which offers commercial enterprise capabilities and premium support as separate offerings. DataHub's maker sells DataHub Cloud, which its README describes as managed, SLA-backed and enterprise-ready with no infrastructure to run. A team that self-hosts the open-source build gets the code, not those managed services, so the paid layer is a separate purchase with its own terms.
The supplied facts do not settle which features sit in each paid tier, and they name no vendor-backed commercial layer for Apache Atlas. Do not assume a feature is free or paid based on this page. Ask each vendor for a written feature matrix per tier that covers single sign-on, role-based access, lineage, connectors, audit logging and upgrade support. For managed offerings, confirm whether the SLA covers only the hosted control plane or also the connectors and pipelines you run, and whether the service meets your data residency rules. For Atlas, confirm which support provider you would use and what that contract includes.
Put licensing and subscription costs in one table with the implementation work. The license fee is zero for all three projects, so recurring costs come from vendor subscriptions and support, and one-time costs come from setup, integration and hardening in your environment. Ask every quote to itemize these separately and to state which items recur each year. Also ask what happens to your metadata and configuration if you later move from a managed tier back to a self-hosted build. The answer determines how locked in you are before you sign.
How to choose and pilot a data catalog
This sequence moves a team from a list of sources and BI tools to a catalog decision backed by a bounded pilot, so the choice between self-hosting and a managed service rests on tested connectors, verified versions and measured server needs.
Inventory sources and BI tools against connector lists
The data platform lead and the owners of each warehouse, pipeline and BI tool list every system the catalog must cover, including the versions in use. Compare that list against the connector catalogs for OpenMetadata (more than 130 connectors) and DataHub (more than 150 integrations listed in its README), and against Apache Atlas hooks, which cover Hive, HBase, Kafka, Sqoop, Storm, Falcon and Couchbase. Mark each system as native connector, community or custom integration, or no integration. Done means every system has a status and every gap has a named owner who will build or accept it.
Confirm Java, database and search versions
The infrastructure owner checks the bare metal prerequisites for OpenMetadata, which require Java 21, MySQL 8.0.42 or later or PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x. For DataHub, confirm the Kafka, MySQL, PostgreSQL or MariaDB, and Elasticsearch or OpenSearch versions required by the Kubernetes guide and current release notes. For Atlas, confirm Java 8, 11 or 17 and the HBase, Solr and JanusGraph setup. Record the versions your standards allow, and raise any mismatch with your platform team before procurement. Done means a signed-off version matrix exists for each candidate.
Size the server and database to documented minimums
The platform engineer compares the documented minimums with your expected load. OpenMetadata's bare metal minimum is 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's Kubernetes guide notes more than 7 GB of RAM to run DataHub and its dependencies on Minikube, and the Docker quickstart requires 8 GB of RAM. Treat these as floors. Size for your source count, metadata volume and search index growth, and ask vendors and DeployOpen for a written sizing basis. Done means a sizing sheet with a stated load assumption is approved.
Run a pilot on a bounded domain
Choose one business domain with a limited number of sources, a named steward and a known set of tables and dashboards. The catalog team ingests metadata for that domain only, then checks search quality, ownership assignment, glossary terms and profiling results against what the domain team expects. Include one ingestion run that fails, and record how the tool reports the failure and how long a re-run takes in your environment. Done means the domain steward signs off that discovery answers their common questions, and the pilot log lists every connector issue found.
Test SSO, access control and audit on real users
The identity team connects the pilot to your identity provider and tests with real accounts from the pilot domain. For DataHub Core, the operator configures OpenID Connect in the frontend server, using the OIDC SSO guide, while DataHub Cloud enables OIDC SSO through its interface. Confirm group mapping, role assignment and what a user without access can see. Also check how the tool logs administrative changes. Ask each vendor which access controls and audit features are in the open-source build and which need a commercial edition. Done means a tested access matrix and an audit sample are filed with the security team.
Validate lineage on production-like pipelines
The data engineering team runs lineage capture on a few real pipelines, including one with a transformation that crosses two systems. Check table and column lineage in the catalog against the actual SQL or pipeline definitions. For OpenMetadata, confirm the OpenLineage event path if you rely on it. For DataHub, confirm column-level lineage on the pipelines that matter. For Atlas, confirm which hooks feed lineage in your stack. Note every lineage edge that is missing or wrong. Done means a lineage accuracy review lists the gaps and the team agrees which gaps block production use.
Decide between managed and self-hosted routes
The platform lead and the security and procurement teams compare the pilot evidence against two routes. The self-hosted route keeps metadata in your infrastructure but leaves upgrades, backups, search tuning and on-call with your team or a services partner. The managed route, such as DataHub Cloud or Collate's commercial OpenMetadata offering, shifts operations to the vendor under its service terms. Ask each vendor for written SLA terms, data residency details and upgrade procedures. Ask DeployOpen for a fixed-scope quote covering implementation, hardening and retainer support. Done means a written decision record names the route, the owner and the open items.
Questions buyers ask before hiring outside help
What drives the effort to self-host each open-source data catalog?
The effort follows the dependency stack more than the feature list. Bare metal 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 to run metadata ingestion. DataHub centers on a metadata service with Kafka, a MySQL or PostgreSQL database, Elasticsearch or OpenSearch, and a graph index. Apache Atlas's documented setups use JanusGraph, Apache HBase and Apache Solr. Each stateful service adds patching, backup, capacity planning and monitoring. The cost components are internal staff time, infrastructure in your own accounts or data centers, and any outside implementation work. Ask each option to list every component it needs, who owns the upgrade path for each one, and how backups of the metadata store and search index are tested.
Can a small team run OpenMetadata or DataHub without outside help?
A small team can run either one alone if it already operates the required databases, search cluster and Kubernetes or bare metal hosts, and if someone owns ingestion schedules from the start. The OpenMetadata bare metal documentation lists minimum server sizing of 2 vCPUs, 4 GB RAM and 20 GB storage, with the database and search services each needing at least 2 vCPUs, 2 GB RAM and 30 GB storage. Those are minimums for a starting point, not a production sizing. DataHub's Docker quickstart requires 8 GB of RAM, which suits a trial. The common gap is ownership of connectors: OpenMetadata lists more than 130 connectors and DataHub lists more than 150 integrations, and each source needs credentials, schedules and fixes when a source changes. Write down who owns each connector before go-live.
What does the DataHub Helm system-update job mean for upgrades?
It means an upgrade is more than swapping container images. The DataHub Kubernetes documentation says the Helm chart runs a system-update job on upgrades to apply schema changes and to reindex search indices when needed. Plan a maintenance window for that job, and test it on a copy of production metadata before touching the live cluster. Take backups of the relational database and the search index first, and confirm that Kafka and the graph index are healthy. The duration depends on the size of your metadata and search index, so measure it in staging and ask your implementation partner to document the rollback path. Ask any outside team whether the upgrade runbook covers the system-update job, the reindex step and a tested restore.
Why is Amundsen left out of this catalog comparison?
Amundsen is excluded because it is archived as of September 2026, so a new deployment would start on a project that is no longer in active development. Confirm its archive status and last activity in its repository before you rely on it, and check whether any internal fork or vendor build is still maintained for your use. If your team already runs Amundsen, the practical question is migration. Plan to move metadata, owners, descriptions and lineage into OpenMetadata, DataHub or Atlas, and test that the lineage and ownership history survive the move. Ask any outside team to scope that migration separately from a new deployment, because the source data and the mapping work differ.
How do Apache Atlas's Ranger and Kafka integrations change the work?
They add integration points you must design, secure and test. The Atlas README says metadata veracity is maintained with Apache Ranger to prevent unauthorized access paths to data at runtime, and that security is both role based and attribute based. That means Ranger policies have to be designed alongside Atlas types, tags and entities, and changes to tags need tests to confirm access results. On the Kafka side, Atlas exposes a messaging interface where hooks send metadata to Atlas and consumers receive change events. The documented hooks cover Hive, HBase, Kafka, Sqoop, Storm, Falcon and Couchbase. Each hook and consumer needs topic configuration, credentials, retry handling and monitoring. Atlas builds with Java 8, 11 or 17, so confirm your build toolchain before scoping the work.
What should a fixed-scope quote for catalog work include?
A fixed-scope quote should list what is built, not only how long it takes. DeployOpen's engagements are typically fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope. Ask for the named platform and version, the sources and connectors in scope, every dependency to be installed, sizing assumptions, SSO and access design, backup and restore testing, upgrade procedures, handover documentation and explicit exclusions. Separate one-time implementation from recurring costs such as infrastructure, license or subscription fees for any commercial edition, internal staff time and optional retainers for upgrades and continuous support. Compare quotes on the same connector list and dependency list, or the numbers will not be comparable.
Does a managed catalog service remove the need for in-house operators?
A managed service removes much of the infrastructure work, but not the ownership work. DataHub's README describes DataHub Cloud as managed, SLA-backed and enterprise-ready with no infrastructure to run, and Collate offers commercial enterprise capabilities and premium support for OpenMetadata. Even so, your team still owns source credentials, connector scope, glossary content, data stewards, classifications and access reviews. Confirm with your compliance and legal teams whether a vendor-hosted environment fits your data residency and audit requirements. Self-hosted DataHub Core also requires the operator to configure the frontend for OIDC single sign-on, so check which identity work moves with a managed option and which stays in-house.
How release activity and upgrades affect your total effort
OpenMetadata has the most visible release cadence of the three, so plan for frequent patching as well as larger upgrades. OpenMetadata 2.0.0 shipped on August 24, 2026, and maintenance releases 2.0.1 to 2.0.5 followed about every one to two weeks, with 2.0.5 dated October 8, 2026. Treat each patch as a change window that includes a test run against your connectors. The 2.0 line also carries breaking changes you must clear before upgrading: embedding credentials move into an llmConfiguration block, Databricks authentication uses a new format, custom ingestion images must be rebuilt for Python 3.12, and Great Expectations must be migrated to 1.3 first. Check the OpenMetadata 2.0 release notes against the connectors and profiler settings you actually run.
DataHub's upgrade effort depends heavily on how you deploy it. On Kubernetes, the Helm chart runs a system-update job during upgrades that applies schema changes and reindexes search when needed, so your maintenance window must allow for reindexing in Elasticsearch or OpenSearch. Measure that time in a staging copy of your metadata before you schedule production. DataHub v1.6.0.3 was released on September 25, 2026, and v1.8.0 release candidates followed in October 2026. Use the candidates to retest your ingestion sources and, on self-deployed DataHub Core, your OIDC SSO configuration, which the operator must set up. Ask the project whether v1.8.0 includes schema migrations and whether the prerequisites chart changes, since both affect your rollback plan. Track the DataHub releases page for the final version.
Atlas moves more slowly, and that changes the effort calculation. Its downloads page lists release 2.3.0 on December 6, 2022, 2.4.0 on January 2, 2025 and 2.5.0 on April 30, 2026, and the repository carries 2.6.0 release candidate tags. Fewer releases mean fewer upgrades, but each one may bundle more change, and you still maintain the surrounding stack: HBase, Solr, JanusGraph, your Ranger policies and Java 8, 11 or 17. Before committing, ask the Apache community which Java version and storage backends the 2.6.0 line supports, how long 2.5.0 will receive fixes, and whether your hooks need retesting. Budget testing time for every upgrade and write the test plan before the first one is due.
How DeployOpen scopes catalog selection and implementation
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For data catalogs, that means turning the choice between OpenMetadata, DataHub and Apache Atlas into a written scope that matches your sources, identity provider and infrastructure.
How we scope
- Inventory the warehouses, BI tools, pipelines and identity providers the catalog must connect to before any platform is chosen.
- Confirm the target infrastructure, including Kubernetes or bare metal, database and search services, and any air-gapped constraints.
- Agree deliverables, timelines and responsibilities in writing, because most engagements are fixed-scope before work starts.
How we build
- Deploy the chosen catalog with its database, search and ingestion dependencies sized to the infrastructure confirmed during scoping.
- Configure single sign-on, role-based access and lineage ingestion for the sources named in the written scope.
- Test connectors, lineage paths and upgrade procedures in a non-production environment before anything goes live.
How we hand over
- Document the architecture, configuration, connector list and known limitations so your team can operate the catalog without us.
- Provide runbooks for backups, restores, version upgrades and any breaking changes that apply to your release line.
- Walk your platform, security and data teams through the handover and record the open items agreed for follow-up.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, scoped separately from the implementation.
- Review each new maintenance release against your configuration before scheduling upgrades in your environment.
- Ask any support provider to confirm response expectations and service terms in writing before you sign.
