Open Source Data Catalog Tools: What Is Maintained, Open Source Data Lineage and True Cost

As of August 2026 there are two open source data catalogs in serious active development: OpenMetadata and DataHub. Both are Apache 2.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 has had zero commits to its main branch in the last 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.

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 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 Apache 2.0 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 publishes a price: datahub.com/pricing returned a 404 when we checked in August 2026, and Collate publishes tier structures and limits with no dollar figures at all.

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.

DataHub vs OpenMetadata: which should you pick?

Both are healthy, both are Apache 2.0, both do column-level lineage, 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 are Apache 2.0 with free column-level lineage.
• Amundsen has had zero commits to main in twelve months and no release since August 2024. Treat it as dormant despite a recent push date.
• 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.