Data catalogs in 2026: revisit OpenMetadata, DataHub and Apache Atlas before you add another metadata platform

Most teams do not decide to build a data catalog. They drift into needing one. A new analyst asks which of three “orders” tables is the real one. A column is renamed in the billing database and a finance dashboard quietly shows zero for a week. A customer’s data protection review asks where personal data is copied after it leaves the main application, and nobody can answer without a day of digging. Somebody installs a catalog, connects everything, and six months later it is a search box full of tables with no owners.

The tool was rarely the problem. What was missing was a clear job, a few owned sources and a habit of keeping metadata true. This post compares the three open-source metadata platforms that most teams shortlist in 2026: OpenMetadata, DataHub and Apache Atlas. It also says a word about Amundsen, which was archived in September 2026, and about Unity Catalog OSS, which solves a different problem even though it shares the word “catalog”.

A catalog sits on top of the rest of your data stack, so it helps to have read a few earlier posts. Lakehouse table formats in 2026 covers the table catalogs that engines need to read Iceberg, Delta and Hudi tables, which are not the same thing as the discovery catalogs here. Data pipeline orchestration in 2026 matters because your orchestrator is one of the best sources of lineage, and OpenMetadata runs its own ingestion on Airflow by default. Change data capture in 2026 and schema registries in 2026 cover the event side, where a schema registry already holds the contract for each topic. Two of the three catalogs here need a search engine, so Elasticsearch and OpenSearch is useful background too.

We end with a small drill that built DataHub metadata and validated an OpenMetadata ingestion file without running any server, and a plain list of what we did not run.

A scenario to keep us honest

Imagine a company in Siliguri that builds software for the tea trade in north Bengal and Assam: garden management for tea estates, sample and lot tracking for auction brokers, warehouse receipts, and payment settlement for buyers. The company is invented for this post. It has about 45 engineers, a four-person data team and one person who looks after security and compliance part time.

The data setup today:

• Three PostgreSQL databases for the main products: estates, auctions and settlements. Debezium streams changes from two of them into Kafka.
• An analytics warehouse on PostgreSQL, built with dbt models that run from Apache Airflow every night and every hour for auction days.
• Raw files and some large history tables in object storage as Iceberg tables, queried with Trino.
• Metabase dashboards for the sales, finance and estate operations teams. There are more than 400 saved questions, and nobody knows which ones still matter.
• An old Hadoop cluster from 2019 with Hive tables of historical auction data. It came with Apache Atlas 1.x, installed by a consultant. Atlas still runs, but nobody has logged in for more than a year.

Four things push the team to revisit this. First, a large buyer’s procurement team sends a data protection questionnaire and asks where the personal data of buyers and estate workers is copied, who can see it, and how long it is kept. Second, in the last auction season a settlements engineer renamed a column, the dbt model failed silently in one branch, and the weekly payment dashboard for estates showed wrong totals for four days. Third, two new analysts spent most of their first month asking on chat which tables to use. Fourth, the old Hadoop cluster is due to be shut down, and the team has to decide whether to keep Atlas, move to something else, or just let it go.

Engineers have proposed OpenMetadata (built-in tests), DataHub (a friend’s company uses it with Kafka) or upgrading Atlas (“we already have it”). We will come back to Siliguri in the worked plan.

The short version

• OpenMetadata is an all-in-one metadata platform: catalog, lineage, glossary, data quality tests, profiler and data contracts, with a Java server, a MySQL or PostgreSQL database, an Elasticsearch or OpenSearch index and a Python ingestion framework that runs on Airflow by default. It is under the Apache License 2.0, and Collate sells a managed version. The latest release is 2.0.7, on 27 October 2026.
• DataHub is a metadata platform built around a strongly typed model and a stream of change events. Its open-source edition, DataHub Core, has a Java metadata service, a frontend, Kafka, a relational database, a search index and optional Neo4j. It supports both pull (scheduled ingestion) and push (systems emit changes). It is under the Apache License 2.0, and the company behind it, formerly Acryl Data and now called DataHub, sells DataHub Cloud. The latest release is 1.8.0, on 22 October 2026, and there is a 1.6.0 long-term support line.
• Apache Atlas is the Hadoop-era governance and metadata framework from the Apache Software Foundation. It stores metadata as a graph on JanusGraph, receives changes from hooks in Hive, HBase, Kafka and others, propagates classifications along lineage, and works closely with Apache Ranger for tag-based access policies. The latest release is 2.5.0, on 30 April 2026. It is the right tool mostly for teams that still run a Hadoop or Ranger based platform.
• Amundsen, the Lyft-born discovery tool, was archived in September 2026. Do not start new work on it. Unity Catalog OSS 0.7.0 is a table and AI asset catalog that engines use to read and write data, closer to the lakehouse catalogs than to a discovery portal.
• The tool matters less than three decisions: which few sources you connect first, who owns each asset, and how lineage and classifications are kept true when code changes. A catalog without owners decays in months whichever one you pick.

Where things stand on 29 October 2026

OpenMetadata. The latest stable release is 2.0.7, published on GitHub on 27 October 2026 at 12:06 PM IST. The release notes describe it as a maintenance release with connector fixes, search consistency improvements, governance and access control fixes, and dependency security updates. One fix is worth reading if you use domains: domain-scoped policies had allowed assets to be moved into domains the user was not authorised for. The 2.0 line itself started with 2.0.0 on 24 August 2026 at 10:52 AM IST, and patch releases have come roughly every week since. The previous line, 1.13, received patches until 1.13.6 on 11 September 2026. A 2.1.0 release candidate was published on 28 October 2026. The Python ingestion package, openmetadata-ingestion, is at 2.0.7.1, uploaded to PyPI on 28 October 2026 at 3:16 PM IST. The project is under the Apache License 2.0.

DataHub. The latest stable release of DataHub Core is 1.8.0, published on 22 October 2026 at 1:47 PM IST. It needs the 1.7.0.14 CLI and Python SDK and Helm chart 1.1.8. It adds support for OpenSearch 3.x next to OpenSearch 2.x and Elasticsearch 8.x, nested data products, and new ingestion sources such as Informix, Monte Carlo and SQLMesh. It also tightens a few defaults: access tokens can no longer be created without an expiry date (existing ones keep working), and reading stored query SQL now needs a separate privilege. DataHub also keeps a long-term support line: 1.6.0 came out on 21 May 2026, and its latest patch, 1.6.0.3, was published on 26 September 2026 at 12:10 AM IST with security and authorisation hardening. A 1.9.0 release candidate appeared on 27 October 2026. The CLI package, acryl-datahub, is at 1.7.0.18, uploaded on 29 October 2026 at 2:07 AM IST. DataHub is under the Apache License 2.0.

Apache Atlas. The latest release is 2.5.0, listed on the Atlas downloads page with a release date of 30 April 2026. Atlas ships source releases; you build it or use a vendor distribution. 2.5 makes the React UI the default, adds a Trino add-on that extracts metadata on a schedule, asynchronous import through Kafka, an automatic purge feature, support for a relational database backend for the graph and for the audit repository, JanusGraph 1.1.0, Hadoop 3.4.2, HBase 2.6 and TLS 1.3. The previous release, 2.4.0, came out on 2 January 2025, and 2.3.0 on 6 December 2022, so releases come roughly once a year or less. Release candidates for 2.6.0 have been tagged, the latest on 16 September 2026, but 2.6.0 was not on the downloads page when we checked. Commits continue in the repository. Atlas is under the Apache License 2.0 and is governed by the Apache Software Foundation.

Amundsen. The repository README says the project was archived in September 2026 due to inactivity; the notice was added on 10 September 2026. The last component releases were in 2024.

Unity Catalog OSS. Version 0.7.0 was released on 14 October 2026 at 2:43 AM IST. It adds Iceberg REST catalog support for table operations, so engines that speak that protocol can create, write and drop Iceberg tables in it. It is under the Apache License 2.0 and is a sandbox project at LF AI and Data.

The first question: what job will the catalog do?

Before comparing tools, write down the one or two jobs the catalog must do in its first six months. The word “catalog” covers very different jobs, and each tool is stronger at some of them.

Common jobs, roughly from easiest to hardest:

• Discovery. Help people find the right table, dashboard or topic, see its description and owner, and know whether it is trusted. This mostly needs good search, ownership and a glossary.
• Impact analysis. Before changing a column, know which models, dashboards and reports depend on it. This needs lineage, ideally at column level, from the places where transformations really happen: dbt, Airflow, Spark, SQL query logs.
• Data quality and contracts. Record and show tests, freshness and volume checks, and promises between producers and consumers. Some tools run the tests themselves; some only display results produced elsewhere.
• Governance and classification. Tag personal or sensitive data, keep a business glossary, track who approved what, and answer audit questions. Some teams also want the catalog to drive access policies.
• Metadata as an event stream. Let other systems react when metadata changes, for example locking down a table when a new column is tagged as personal data.

Then write down what the catalog will not do. It is not your access control system unless you wire it to one. It does not fix bad data; it shows where bad data comes from. It does not replace a schema registry for events, or the table catalog your engines use for Iceberg. And it does not write descriptions. People do.

For Siliguri, the first two jobs are clear: impact analysis for the settlement and payment pipeline, and an honest map of where personal data goes. Discovery for new analysts comes free if those two are done well.

What each tool is

OpenMetadata

OpenMetadata was announced in 2021 by Suresh Srinivas and Harsha Chintalapani, who had built metadata systems at Uber and, before that, worked on Hadoop at Hortonworks. Suresh was also on the project management committee of Apache Atlas. Their announcement post explains the choice to start fresh rather than open-source Uber’s internal tools: company-specific needs and frameworks were hard to separate. The company behind the project is Collate, which offers a managed service.

The design is schema-first. Every entity type, such as a table, a dashboard, a pipeline, a glossary term or a test case, is defined in a JSON Schema, and the server, the APIs and the Python ingestion models are generated from those schemas. In practice that means:

• A Java server with a REST API and a web UI.
• A relational database, MySQL or PostgreSQL, which is the source of truth for metadata.
• Elasticsearch or OpenSearch for search, rebuilt from the database when needed.
• A Python ingestion framework with connectors for databases, warehouses, dashboards, pipelines, message queues, ML tools and object stores. Workflows are described in YAML. By default they are deployed to and scheduled on an Airflow instance that ships with OpenMetadata, but you can run them from your own scheduler with the metadata CLI.

A small database ingestion workflow looks like this. The values are invented; this is the same file our drill validated.

source:
  type: postgres
  serviceName: billing_pg
  serviceConnection:
    config:
      type: Postgres
      username: catalog_reader
      authType:
        password: not-a-real-password
      hostPort: 127.0.0.1:5432
      database: billing
  sourceConfig:
    config:
      type: DatabaseMetadata
      schemaFilterPattern:
        includes:
          - public
sink:
  type: metadata-rest
  config: {}
workflowConfig:
  openMetadataServerConfig:
    hostPort: http://127.0.0.1:8585/api
    authProvider: openmetadata
    securityConfig:
      jwtToken: not-a-real-token

Beyond the catalog, OpenMetadata includes a profiler, no-code data quality tests at table and column level, data contracts that can be imported from and exported to the Open Data Contract Standard (ODCS), a glossary and classification system, domains and data products, tasks and announcements, and a role and policy engine. The 2.0 release also turned on a Model Context Protocol (MCP) server by default, so AI assistants can query the catalog.

DataHub

DataHub started at LinkedIn. Its predecessor, WhereHows, was open-sourced in 2016. LinkedIn described the redesigned DataHub in August 2019 and released it officially on GitHub in February 2020. Some of the founding engineers then formed Acryl Data, which rebranded itself as DataHub in 2025. The open-source edition is now called DataHub Core and the managed edition DataHub Cloud. The docs mark Cloud-only features clearly.

The design idea is a typed metadata model and a log of changes:

• Every entity, such as a dataset, a dashboard, a data job, a user or a glossary term, is identified by a URN and described by small, versioned pieces called aspects (ownership, schema, tags, upstream lineage and so on).
• Every change is a Metadata Change Proposal. Proposals can be sent over HTTP for a synchronous answer, or over Kafka for high-volume, asynchronous publishing.
• The metadata service (GMS) writes the change to a relational database (MySQL, PostgreSQL or MariaDB) and emits a change log event. Consumers update the search index and the graph index from that stream. Other systems can subscribe to the same stream through the DataHub Actions framework.

Ingestion can be pull or push. Pull uses the Python ingestion framework with “recipes”: a YAML file with a source, optional transformers and a sink, usually the DataHub REST endpoint. Push uses small emitters in Python or Java that send changes from the point of origin, for example from an Airflow task, a Spark job or your own service. DataHub also accepts OpenLineage events.

source:
  type: postgres
  config:
    host_port: 127.0.0.1:5432
    database: billing
    username: catalog_reader
    password: "${BILLING_PG_PASSWORD}"
sink:
  type: datahub-rest
  config:
    server: http://127.0.0.1:8080

DataHub Core includes search, lineage at table and column level, a glossary, domains, data products, structured properties, incidents and a policy system for who can view and edit what. For data quality, Core stores and displays assertion results, and can build data contracts from them, but the docs say that scheduling and running assertions inside DataHub is part of DataHub Cloud. In Core you run checks elsewhere, for example dbt tests or Great Expectations, and publish the results.

Apache Atlas

Atlas entered the Apache Incubator on 6 May 2015 and graduated to a top-level project on 21 June 2017. It was built for the Hadoop world, and it shows in good and bad ways.

• Type system. You define types with attributes, inheritance and relationships. Hive tables, Kafka topics, HBase tables and processes are all types. You can add your own.
• Graph store. Entities and relationships live in a graph on JanusGraph, traditionally backed by HBase and indexed with Solr. Atlas 2.5 adds support for a relational database backend.
• Hooks and notifications. Hooks inside Hive, HBase, Sqoop, Storm, Kafka, Impala and Spark send metadata changes to Kafka topics as they happen, and Atlas consumes them. This is push by design. Atlas also publishes its own change events for others.
• Classifications and propagation. Classifications such as PII or SENSITIVE can carry attributes and can propagate along lineage, so a derived table can inherit the classification of its source.
• Ranger integration. Apache Ranger can use Atlas classifications for tag-based access policies and masking, for example letting a support team see only the last four digits of a column classified as a national identifier.

Atlas has a capable REST API and a search language (DSL). What it does not have is a broad set of connectors to modern SaaS warehouses, BI tools and dbt. Its strength is deep, push-based integration with the Hadoop components and Ranger.

A word on Amundsen and Unity Catalog OSS

Amundsen was one of the first open-source discovery tools, from Lyft, and many teams started with it around 2019 to 2021. Its README now says it was archived in September 2026 due to inactivity. It will not break overnight, but there will be no more fixes, including security fixes. Plan a move; its databuilder jobs are a ready list of the sources you care about.

Unity Catalog OSS is a different kind of catalog. It manages tables, volumes, functions and models so that engines like Spark can read and write them with access control, and 0.7.0 adds Iceberg REST catalog operations. It is closer to the table catalogs in our lakehouse post than to a discovery and lineage portal. Some teams will run both: a table catalog for engines, and a metadata platform on top that also covers dashboards, pipelines and people. OpenMetadata, for example, has a Unity Catalog connector.

Side by side

Licence and governance

All three are under the Apache License 2.0, so the licence itself is not a reason to choose one over another. The difference is who steers the project.

• OpenMetadata is steered by Collate, which employs most maintainers and sells a managed version. Features generally land in the open-source project, and the hosted version adds operations and some extra capabilities.
• DataHub Core is steered by the DataHub company, which sells DataHub Cloud. The docs separate Core and Cloud features clearly. Some data quality and observability features, such as running assertions on a schedule, are Cloud only.
• Apache Atlas is steered by its Apache project management committee under ASF rules. There is no single company that sells “Atlas Cloud”. In practice, much of its development has come from companies that ship Hadoop distributions.

Read the feature split before you commit. If your main reason is a paid-edition feature, you have picked the paid edition.

Architecture and moving parts

• OpenMetadata: server, MySQL or PostgreSQL, Elasticsearch or OpenSearch, and Airflow for ingestion (or your own scheduler). Four components to run if you use the bundled Airflow.
• DataHub: frontend, GMS, optional separate consumers for change events, Kafka (with a schema registry in the default setup), MySQL, PostgreSQL or MariaDB, Elasticsearch or OpenSearch, and optionally Neo4j for the graph. The Helm chart can run the consumers inside GMS and use the search engine as the graph store, which reduces the count.
• Apache Atlas: the Atlas server, a graph backend (JanusGraph on HBase, or the newer relational option), Solr for the index, and Kafka for hooks and notifications, plus ZooKeeper when you run it in high availability mode. On a Hadoop cluster, most of these already exist. Without Hadoop, Atlas is a lot of infrastructure for one application.

Ingestion: pull, push and connectors

• OpenMetadata is mainly pull. Connectors read metadata, query logs and usage from sources on a schedule. You can also push through the REST API and SDKs, and there is an OpenLineage path for lineage events. It has a wide set of connectors for databases, warehouses, BI tools, pipelines, messaging, ML and storage.
• DataHub is designed for both. Pull with recipes on a schedule, or push changes as they happen through REST or Kafka. Its connector list is also wide and includes dbt, Airflow, Spark, Kafka, most warehouses and BI tools.
• Apache Atlas is mainly push through hooks inside Hadoop components, with some batch import tools and the new Trino add-on. Connectors for modern warehouses and BI tools are limited.

Push gives fresher metadata and lineage that reflects what actually ran; pull is simpler for systems you do not control. Most teams end up with pull for databases and BI tools and push for pipelines.

Lineage

Lineage is the feature people buy a catalog for and then find hardest to keep true.

• Table-level lineage is fairly easy: from dbt manifests, Airflow task definitions, view definitions, and SQL query logs.
• Column-level lineage needs SQL parsing or tool metadata. OpenMetadata and DataHub both parse SQL from view definitions and query logs for many systems, and read column lineage from dbt. Results depend on SQL dialect and on how dynamic your SQL is.
• Atlas gets lineage from its hooks, for example Hive queries and Spark jobs, and 2.5 improves Impala lineage for queries with WITH clauses.

Whichever tool you pick, test lineage on your own worst queries before you promise impact analysis to anyone. Stored procedures, dynamically built SQL and Python transformations are where it breaks.

Data quality and contracts

• OpenMetadata runs tests itself through its ingestion framework: table and column tests, custom SQL tests, a profiler, and data contracts with ODCS import and export. In 2.0 the profiler samples rows dynamically by default instead of scanning whole tables, and stops collecting cardinality distribution by default, which lowers query cost but can surprise rules that depended on distinct counts.
• DataHub Core stores assertions and contract status and shows them, and reads results from dbt test runs and Great Expectations. Running assertions on a schedule from DataHub is a Cloud feature.
• Apache Atlas has no built-in data quality testing. You can model quality results as classifications or attributes.

If you already run dbt tests, you mainly need a place to show results next to the asset. If you have no tests, OpenMetadata’s built-in tests are an easy start, but the catalog then becomes part of your data quality path and its uptime starts to matter.

Access, security and the catalog’s own risk

A catalog holds connection credentials for many databases, query text that may contain personal data, and sample rows if you turn on profiling or sampling. Treat it as a sensitive system.

• OpenMetadata documents a clear security model. Administrators are trusted like network operators, because they can make the server connect to any host it can reach. Under the default policy, any logged-in user can claim ownership of a service connection or ingestion pipeline that has no owner, and ownership gives full control. The docs ask operators to assign owners when creating them, restrict egress, use read-only credentials for each source, block the cloud metadata endpoint, use a secrets manager, and keep audit logs.
• DataHub 1.8.0 stopped allowing new access tokens without expiry and put stored query SQL behind its own privilege; the 1.6.0.3 LTS patch hardened secret handling. Its CLI sends usage telemetry by default; set DATAHUB_TELEMETRY_ENABLED=false where that is not wanted. We confirmed the default in the CLI source during the drill.
• Apache Atlas supports Kerberos, LDAP, PAM and Keycloak for login and can hand authorisation to Ranger, and its classification-driven policies through Ranger are its strongest governance feature.

In all three, put the catalog behind your single sign-on, give each connector a read-only account that can read metadata and nothing else, and decide on purpose whether sample data and full query text are collected.

Operations and upgrades

• OpenMetadata upgrades run a database migration. The docs ask you to back up the database with mysqldump or pg_dump first. The 2.0 upgrade had several breaking changes: embedding settings for semantic search moved to a new block and stop working silently if not moved, a Databricks connector field changed shape, and ingestion images moved to Python 3.12, so custom images with older compiled wheels fail. Patch releases come about weekly.
• DataHub upgrades run a system-update job that applies schema changes and reindexes search when needed. The Helm chart runs it as hooks before and after the upgrade; if your pipeline renders the chart with helm template and applies YAML, you must run those phases yourself. 1.8.0 changed search document ids for the newer search index, which needs a clean restore or reindex in some cases. The 1.6.0 LTS line exists for teams that want fewer upgrades.
• Apache Atlas upgrades follow the Hadoop stack. Releases are rare and source only, so most teams depend on a vendor distribution or build their own.

Resource footprint

These are the projects’ own published guidance, not our measurements.

• OpenMetadata lists, for a production deployment, 4 vCPUs and 16 GiB memory for the server, 4 vCPUs and 16 GiB for the database with at least 100 GB of storage, 2 vCPUs and 8 GiB per search node with at least one master and two worker nodes, and 4 vCPUs and 16 GiB for Airflow. It needs MySQL 8.0.42 or newer or PostgreSQL 15 or newer, and Elasticsearch 9 or OpenSearch 3.4 or newer. The docs warn that OpenSearch 3.0 to 3.3 have a bug that breaks plain-text search with 2.0.
• DataHub says its Docker quickstart is tested with 2 CPUs, 8 GB memory, 2 GB swap and 13 GB disk, and that a local Kubernetes test needs more than 7 GB of memory. A production setup adds Kafka, a database and a search cluster, which you may already run.
• Apache Atlas needs HBase, Solr and Kafka, or the new relational backend. On an existing Hadoop cluster that is shared cost; without one, it is the heaviest of the three.

For a mid-sized company, the people time to keep metadata useful usually costs more than the servers.

A worked plan for Siliguri

Step 1: Write down the jobs and the non-jobs. Job one: impact analysis for the settlements pipeline, from the PostgreSQL source tables through dbt to the Metabase payment dashboards. Job two: a map of where personal data of buyers and estate workers is stored and copied. Non-jobs for now: access control, running data quality tests, and a company-wide glossary.

Step 2: Pick the first sources, not all sources. The settlements database, the dbt project, Airflow, the analytics warehouse and Metabase. Kafka topics and Iceberg tables come in the second month. The old Hive tables come only if they survive the Hadoop shutdown.

Step 3: Decide what to do with Atlas. Atlas is tied to a cluster that is being shut down, has not been used in a year, and has no connectors for dbt or Metabase. Siliguri exports a list of the classified Hive tables from Atlas through its REST API, stores it in Git as a record, and plans to switch Atlas off with the cluster. A team that is keeping Hadoop and Ranger for years would reasonably keep and upgrade Atlas instead.

Step 4: Choose between two paths with a two-week trial each.

• Path A: OpenMetadata. One platform for catalog, lineage and simple tests. Ingestion runs on its bundled Airflow, or the team can trigger workflows from its own Airflow. Moving parts: server, PostgreSQL, OpenSearch 3.4 or newer, and the ingestion runner.
• Path B: DataHub Core. Push lineage from Airflow and dbt, pull for databases and Metabase. The team already runs Kafka for Debezium, which lowers the extra cost. Data quality results would come from dbt tests.

Both trials use the same five sources and three test questions: “What breaks if settlements.payments.amount is renamed?”, “Where does buyer_phone go?” and “Who owns the weekly estate payment dashboard?”.

Step 5: Choose. Siliguri picks OpenMetadata (Path A). The deciding reasons are plain: the data team is small and wants simple tests next to the lineage, and it would rather not make its Kafka cluster part of the catalog’s write path. A team with a strong platform group, more push-based sources and plans to react to metadata events could reasonably choose DataHub.

Step 6: Install it like a production system. PostgreSQL for metadata, with nightly pg_dump backups that are restored once a month on a test machine. OpenSearch at a version the docs support. Single sign-on through the company’s identity provider. Each connector uses a dedicated read-only database user. Sample data collection is off for the settlements and estates databases. Every service connection and ingestion pipeline gets an owner when it is created, as the security model page advises.

Step 7: Ownership before descriptions. Each source table and each dashboard in the first scope gets an owning team. Descriptions are written only for the 40 assets that the payment dashboards use. The rest wait.

Step 8: Classification with a review. Use automatic classification as a suggestion, then have the data owner confirm tags for personal data columns. Check that derived tables carry the tag too; our drill showed how easily the source is tagged and the copy is not. Add the confirmed list to the answer for the buyer’s questionnaire.

Step 9: Put lineage into the change process. Before a pull request changes a column in the settlements database or a dbt model in the payments folder, the author checks downstream assets in the catalog and lists them in the pull request. Add a dbt test for the four payment totals so the next silent failure is loud.

Step 10: Make upgrades routine. Track the stable line, read the release notes for breaking changes, take a database backup, upgrade staging first, and run the three test questions again after every upgrade. Set a target of one month for patch releases and a quarter for minor releases.

When each is better

• OpenMetadata is better when you want one platform for discovery, lineage, glossary and simple data quality tests, with a relational database as the source of truth and fewer moving parts than a Kafka-based design. It suits small and mid-sized data teams that want to start fast and accept a weekly patch cadence.
• DataHub is better when you want metadata as a stream, push-based lineage from many systems, a strongly typed and extensible model, or federated ownership across teams. It suits teams that already run Kafka and a search cluster and have platform engineers who can operate them. Choose the LTS line if you want fewer upgrades.
• Apache Atlas is better when you run a Hadoop-style platform with Hive, HBase, Kafka and Ranger and need classification-based access policies and masking that follow lineage. Outside that world, it is usually more infrastructure than value.

When not to change, or not to add a catalog

• You have fewer than a few dozen important tables and one small team. A well-kept dbt project with generated docs, column descriptions and a README per domain may answer most questions. Add a catalog when people outside the data team need to find data.
• Nobody will own metadata. A catalog with no owners and no descriptions is worse than none, because people stop trusting it and stop looking.
• Your warehouse or cloud platform already has a catalog you are paying for and it covers your sources. Use it well before adding a second one.
• Your current catalog works and is current. If people use it and it is on a supported release, do not switch for a feature list.
• The real problem is elsewhere. If the settlement dashboard broke because there were no tests, a catalog will show the break; tests will prevent it. Fix the tests first.
• You need access control, not a catalog. Database roles, row-level security and your identity provider do that job. A catalog can document it, and Atlas with Ranger can drive it, but OpenMetadata and DataHub Core do not enforce access on your databases.

A short history

• 6 May 2015: Apache Atlas enters the Apache Incubator.
• 2016: LinkedIn open-sources WhereHows, DataHub’s predecessor.
• 21 June 2017: Apache Atlas graduates to a top-level Apache project.
• August 2019: LinkedIn describes DataHub; its post already lists Lyft’s Amundsen among similar tools.
• February 2020: LinkedIn officially releases DataHub on GitHub.
• August 2021: the OpenMetadata repository is created; the project is announced that year.
• 25 April 2023: OpenMetadata 1.0.0.
• June 2024: Unity Catalog’s open-source repository appears; it later becomes an LF AI and Data sandbox project.
• 2 January 2025: Atlas 2.4.0.
• 2025: Acryl Data rebrands as DataHub, with DataHub Core as the open-source edition and DataHub Cloud as the managed one.
• 30 April 2026: Atlas 2.5.0, with a relational backend option and a React UI by default.
• 21 May 2026: DataHub 1.6.0, the start of a long-term support line.
• 24 August 2026: OpenMetadata 2.0.0.
• September 2026: Amundsen is archived.
• October 2026: Unity Catalog OSS 0.7.0 (14 October), DataHub 1.8.0 (22 October) and OpenMetadata 2.0.7 (27 October).

Decision guide

• Do you need discovery, lineage and simple data quality tests in one place, with a small team? Start with OpenMetadata.
• Do you already run Kafka and want push-based, near real-time metadata and event-driven automation? Start with DataHub Core, on the LTS line if upgrades worry you.
• Do you run Hadoop, Hive and Ranger and need tag-based access policies? Keep or upgrade Apache Atlas.
• Do you run Amundsen? Plan a move; it is archived.
• Do you need engines to find and govern tables in a lakehouse? That is a table catalog job, such as Unity Catalog OSS or an Iceberg REST catalog, not a discovery catalog. You may need both.
• Is nobody available to own metadata? Do not add a catalog yet.

Checklist

• The first two jobs and the non-jobs of the catalog are written down.
• The first five or so sources are chosen; the rest wait.
• The platform runs on a current release (OpenMetadata 2.0.7, DataHub 1.8.0 or 1.6.0.3 LTS, Atlas 2.5.0 as of 29 October 2026).
• The metadata database is backed up and a restore has been tested.
• Search engine versions match the platform’s supported list.
• Single sign-on is on, admin rights are limited to a few named people, and tokens expire.
• Each connector uses a read-only account; sample data and query text collection are decided per source.
• Every service connection, pipeline and important asset has an owner.
• Lineage has been tested on your hardest queries, not only on demo data.
• Classifications for personal data are reviewed by owners and checked on derived tables.
• Upgrades follow a routine: read notes, back up, staging first, re-run test questions.

Common mistakes

• Connecting every source on day one. Thousands of empty assets bury the few that matter.
• Treating the catalog as documentation that writes itself. Connectors bring names and schemas, not meaning.
• Tagging the source and forgetting the copies. Personal data spreads through staging tables and extracts.
• Using an admin database account for ingestion. The catalog then holds the keys to every database.
• Leaving sampling on for sensitive tables. Profilers can copy real rows into the catalog.
• Picking a tool for a paid-edition feature and finding it missing in the open-source edition.
• Skipping release notes. Breaking changes in configuration can turn features off silently.
• Keeping an unused catalog running. It is still an attack surface and a cost.

The drill we ran

We wanted to see how the two most popular platforms describe metadata and ingestion, without running a server, a search engine or Docker. Everything ran in a scratch folder with two Python virtual environments. No sudo, no services, nothing listening on any port.

1. Setup. acryl-datahub 1.7.0.18 in one virtual environment and openmetadata-ingestion 2.0.7.1 in another, both on Python 3.13. The DataHub CLI warned that versions above 3.11 are not actively tested. We set DATAHUB_TELEMETRY_ENABLED=false after confirming in the installed source that telemetry is on by default.
2. DataHub model. A short Python script built five aspects for three invented tables (an invoices table, a staging table and a weekly payments mart): a description, a pii tag and an owning team on the source, and upstream lineage with column-level mappings on the other two. It wrote them as Metadata Change Proposals to a local JSON file.
3. DataHub checks. “datahub check metadata-file” reported all five records valid. A recipe with a file source and a file sink ran the full ingestion pipeline locally and wrote the same five records back out with no warnings. A second recipe with “path” misspelt failed at configuration time with a clear “Field required” message before any metadata moved.
4. Impact question. A small script walked the column-level lineage in the file. The amount column flowed from invoices to staging to the weekly mart. The buyer_phone column flowed into the staging table, but only the source table carried the pii tag. That is the classic gap: lineage tells you where a column goes; it does not tag the copy for you. We did not test any tool’s classification propagation.
5. OpenMetadata workflow. We validated the PostgreSQL ingestion YAML shown earlier against the workflow models in openmetadata-ingestion, with no server running. The correct file parsed as an OpenMetadata workflow with a PostgreSQL connection and the REST sink. The same file with hostPort misspelt as hostport failed with “Extra parameter ‘hostport’” and “Missing parameter ‘hostPort’”. No connection was attempted. No drill processes were left running.

Not run: no OpenMetadata, DataHub or Atlas server, no search engine or Kafka, no ingestion from a real database, no SQL lineage parsing, no profiler or data quality tests, no UI, no authentication, no upgrade, and nothing for Unity Catalog or Amundsen. There are no performance numbers in this post. Treat the drill as a look at how the tools model metadata and check configuration, not as a comparison.

Unlearn, re-learn

• Unlearn “a catalog is a search box for tables”. Re-learn that it is useful only when it answers specific questions: what breaks, where personal data goes, who owns this.
• Unlearn “connect everything and it will fill itself”. Re-learn to start with a few sources and owners, and grow from there.
• Unlearn “lineage is automatic”. Re-learn that it is as good as your SQL, your job integrations and your tests of it.
• Unlearn “open source means every feature is free”. Re-learn to read the Core and Cloud split before you choose.
• Unlearn “we already have Atlas, so we have a catalog”. Re-learn that a tool nobody opens is not a catalog, and that Atlas fits best where Hadoop and Ranger still live.
• Unlearn “the catalog is harmless metadata”. Re-learn that it holds credentials, query text and sometimes sample rows, and needs the same care as a database.

Sources

• OpenMetadata: OpenMetadata repository, OpenMetadata releases, 2.0.0 release notes, 2.0.7 release notes, minimum requirements, production-ready requirements, security model, backup and restore, data contracts, openmetadata-ingestion on PyPI, Announcing OpenMetadata, Collate Series A post
• DataHub: DataHub repository, DataHub releases, release notes, architecture overview, ingestion architecture, deploying with Kubernetes, quickstart, data contracts, assertions, acryl-datahub on PyPI, Open sourcing DataHub (LinkedIn Engineering), DataHub Series B and rebrand announcement
• Apache Atlas: Apache Atlas home, Atlas repository, downloads page source with release dates, what’s new in 2.5, architecture, Atlas incubation status
• Amundsen: Amundsen repository and archive notice
• Unity Catalog OSS: Unity Catalog repository, Unity Catalog 0.7.0 release
• Related posts on Revisit.Tech: lakehouse table formats in 2026, data pipeline orchestration in 2026, change data capture in 2026, schema registries in 2026, Elasticsearch and OpenSearch, PostgreSQL backups in 2026