DataTrail
Blog / Comparisons 9 min read

Open Source Data Catalog Tools Still Maintained, Their Lineage and True Cost

DataTrail

Lineage map
›Lineage mapped from query history. Read-only connection.
0

Read-only connection. DataTrail never moves or mutates your data.

As of August 2026 there are two open source data catalogs in serious active development: OpenMetadata and DataHub. DataHub is Apache 2.0 throughout; OpenMetadata's server is Apache 2.0 but its ingestion framework and UI moved to the source-available Collate Community License at version 1.6.0. Both ship real column-level lineage in the free edition, and both had commits land this week. Apache Atlas is still maintained but is a Hadoop-era tool. Amundsen was formally archived on GitHub in September 2026 ("Due to inactivity, this project was archived," its README now says, re-read 15 September 2026) after zero commits to its main branch in the preceding twelve months, and Marquez has had five. None of the four monitors your data, because in every one of these projects freshness and anomaly detection are commercial features.

That is the short answer. The longer one matters because the usual way people check whether an open source project is alive gives the wrong result on two of these five, and because the license fee is the smallest part of what a self-hosted catalog costs.

Open source data catalog tools compared

Every figure below was pulled from the GitHub API on 19 August 2026 rather than copied from another comparison post, so it is a snapshot you can reproduce in about a minute.

ProjectStarsLatest releaseCommits to main, last 12 monthsColumn-level lineage
OpenMetadata14,9001.13.3 stable, 31 Jul 2026 (2.0.0-rc2 on 13 Aug)DailyYes, across the modern stack
DataHub12,500v1.7.0, 4 Aug 2026DailyYes, 60+ sources, free edition
Amundsen4,800databuilder-7.5.1, Aug 20240 (repository archived Sep 2026)No
Marquez2,3000.50.0, Oct 20245Only what producers emit
Apache Atlas2,1002.5.0, 30 Apr 2026100+Hive, Spark and Sqoop only

Why the GitHub "last updated" date is misleading

Here is the trap. Amundsen's repository reports a pushed_at date of 1 August 2026. On a dashboard, on a vendor comparison page, in most people's quick sanity check, that reads as a project updated three weeks ago. Query the commit history on the default branch over the same period and you get zero. The project confirmed the reading itself a few weeks later: on 15 September 2026 the GitHub API returns archived: true for amundsen-io/amundsen and the README opens with "Due to inactivity, this project was archived in September 2026. The contents will remain available for historical purposes."

The reason is that pushed_at counts a push to any ref in the repository, including branches nobody merges and refs created by automation. It is not a measure of whether the project is moving. The honest signals are narrower:

  • Commits to the default branch over twelve months. This is the one that separated Amundsen (zero) from Atlas (over a hundred) in the table above, and the two projects have almost identical reputations for being sleepy.
  • Date of the last stable release. Amundsen's is August 2024. Marquez's is October 2024. A project that still merges the occasional fix but has not cut a release in nearly two years is not one you want under a governance program.
  • Whether pull requests get merged, not just opened. A long queue of open PRs with no merges is the clearest sign that maintainer attention has moved on.

Run those three checks yourself before you commit a quarter to a deployment. Two API calls and a look at the releases page will tell you more than any listicle, including this one, because the numbers move.

Which open source data catalogs have column-level lineage?

DataHub and OpenMetadata both do, properly, in the free self-hosted edition. That is worth pausing on, because several commercial platforms treat column-level lineage as a paid tier or a per-connector add-on. Alation's own documentation makes table-level the default and requires a purchased parser add-on for Snowflake column lineage. Getting it free from an open source project is a genuine advantage, not a consolation prize.

DataHub publishes a lineage support matrix listing more than sixty ingestion sources with column-level lineage, including Snowflake, BigQuery, Databricks, Redshift, dbt, Looker, Tableau and Power BI, generated by a SQL parser built on sqlglot that DataHub says reaches 97 to 99% accuracy. Roughly seventeen sources are table-level only, among them Airbyte, Informatica, Kafka Connect, Metabase, NiFi, Salesforce and Superset. Check your connector specifically rather than trusting the headline. The full picture is in our DataHub data catalog comparison.

Apache Atlas is the one most comparisons get wrong. Atlas does have column-level lineage, and has since the 0.8-incubating release: a ColumnLineageProcess entity relates an output column to its input columns, and it records the dependency type as SIMPLE, EXPRESSION or SCRIPT. The catch is where it comes from. Atlas gets lineage from hooks in Hadoop-native engines, which means Hive, Spark and Sqoop. There is no general SQL parser reading your Snowflake query history. If your stack is Hive on-premises, Atlas is a reasonable answer and the Atlas comparison goes deeper. If your stack is a cloud warehouse and dbt, it is the wrong tool, not an out-of-date one.

Marquez is a different category again. It is the reference backend for the OpenLineage standard rather than a scanner, so it displays whatever your instrumented jobs choose to emit. Column lineage arrives only when an integration populates the ColumnLineageDatasetFacet, which in practice mostly means Spark. Nothing that is not instrumented appears at all, which we cover in more detail in the guide to how OpenLineage tracks lineage.

What does it actually cost to self-host a data catalog?

The license is free. The infrastructure is not, and this is where self-hosting budgets usually break.

DataHub's Kubernetes guidance states plainly that "more than 7GB of RAM is required to run DataHub and its dependencies", and those dependencies are four separate systems you now operate: Kafka, a relational database, a search index, and a graph index that is either Neo4j or Elasticsearch. On top sit four DataHub components of its own. OpenMetadata is lighter but not light, with a production deployment typically running four services at roughly 10 vCPU and 40 GiB.

So the real comparison is never "free versus $X per month". It is "free plus a fraction of a platform engineer, forever, versus $X per month". Somebody has to size those clusters, keep them patched, restore them when the search index corrupts, and be awake when the graph database runs out of disk at 2am. If that work is not already a funded part of somebody's job, the honest move is to budget for the ongoing server and deployment operations up front rather than discover it in month three. For a five-person data team, the fully loaded cost of that engineer time usually exceeds the subscription it was meant to avoid. For a fifty-person platform org that already runs Kafka and Elasticsearch, the marginal cost is genuinely small and self-hosting wins easily.

What every open source data catalog leaves out

This is the gap that surprises people three months in. None of these projects monitor your data in the free edition. They catalog it, they search it, and the two healthy ones map lineage across it. They do not tell you that a table stopped refreshing.

DataHub's own documentation lists freshness, volume, schema and column monitoring, custom SQL checks, AI anomaly detection, the data health dashboard, assertion notifications and pipeline circuit breakers as DataHub Cloud features. OpenMetadata's commercial sponsor, Collate, follows the same open-core pattern. Neither company prints a price on its own website: datahub.com/pricing is a 404 and Collate publishes tier limits with no dollar figures. Both do print one on AWS Marketplace, re-checked 21 September 2026, and it is the same number: DataHub Cloud lists at $75,000 for 12 months for up to 20 monthly active users, and Collate Premium at $75,000 for 25 users and 5,000 data assets.

That is a completely normal business model and both projects are transparent about it in their docs. But it means the plan "we will just self-host, it is free" resolves to one of two very different projects. Either you are adopting a free catalog and still have no answer to data reliability, or you are opening a procurement conversation with no list price to anchor against. Deciding which one you are doing on day one saves a lot of awkwardness in the second quarter.

Should you pick DataHub or OpenMetadata?

Both are healthy and both do column-level lineage, though only DataHub is Apache 2.0 end to end (OpenMetadata's ingestion framework is under the Collate Community License, which bars offering it as a competing hosted service; the full license comparison is in OpenMetadata vs DataHub), and the feature lists are close enough that the decision rarely turns on them. OpenMetadata is currently the more popular by stars, roughly 14,900 to 12,500, and it shipped eight releases in the two months to mid-August 2026 with a 2.0 release candidate in progress. Its single unified metadata schema is faster to reason about on day one. The counterweight is that breaking changes have shipped in patch releases, so pin your versions and read the notes.

DataHub has the more extensible entity model, the larger connector catalog, and a stronger story if your metadata needs are unusual. It is the heavier deployment because of the Kafka and graph index dependencies. One naming point that catches people researching it: the company Acryl Data renamed itself DataHub in May 2025, the Python package is still acryl-datahub, and datahub.io is an unrelated Open Knowledge Foundation site.

The practical advice is unglamorous. Deploy both in a sandbox, point them at your own warehouse, and look at the lineage graph they produce for the five tables you care most about. Connector quality varies far more between sources than the marketing pages admit, and thirty minutes of that will settle the question better than another week of reading.

When a managed tool is the better call

Self-host when you have platform capacity, a hard requirement to keep everything inside your own perimeter, or an existing Kafka and Elasticsearch estate that makes the marginal cost near zero. The two healthy projects are genuinely good software and the communities behind them are active.

Buy instead when the constraint is time and headcount. That is the case DataTrail is built for: column-level lineage parsed from your query history and dbt manifest, downstream impact analysis that tells you what a column change breaks before you merge, and freshness and schema change monitoring in the same product rather than in a cloud tier you have to negotiate for. It connects read-only, there is nothing to operate, and the price is published. The wider field, commercial and open source together, is compared in our guides to data catalog tools and metadata management tools.

The short version

  • OpenMetadata and DataHub are the two actively developed open source data catalogs in August 2026. Both ship free column-level lineage. DataHub is Apache 2.0 throughout; OpenMetadata's ingestion framework and UI are under the Collate Community License.
  • Amundsen was archived by its maintainers in September 2026 after zero commits to main in twelve months and no release since August 2024. It is read-only now, not dormant.
  • GitHub's pushed_at is not a maintenance signal. Check commits to the default branch, the last stable release date, and whether PRs get merged.
  • Apache Atlas is maintained, released 2.5.0 in April 2026, and does have column-level lineage, but only from Hive, Spark and Sqoop hooks.
  • Marquez is an OpenLineage backend, so it shows only what instrumented jobs emit.
  • The license is free; the infrastructure is not. DataHub needs more than 7GB of RAM and four dependency systems, OpenMetadata roughly 10 vCPU and 40 GiB.
  • No open source edition monitors data quality. Freshness and anomaly detection are commercial features in both healthy projects, and neither vendor publishes a price.

See how your data flows, end to end

Connect your warehouse read-only and map lineage, freshness, and downstream impact before a change breaks a dashboard. Transparent pricing, no card to start.