Data Catalog & Lineage

The "where does this column come from, who owns it, who uses it" layer. Pairs naturally with Data Transformation & Modeling (dbt's manifest.json is a lineage source) and Data Quality & Testing.

Catalogs (full-featured)

• ★ DataHub (Acryl Data) — Apache 2.0; LinkedIn-origin; entity-graph model; broad connector library; React UI. The dominant OSS catalog in 2026; Acryl Cloud is the paid hosted version.
• ★ OpenMetadata — Apache 2.0; metadata + quality + lineage in one app; opinionated UI; growing fast. Often picked over DataHub for "easier to deploy."
• Apache Atlas — Hadoop-era; still around in big-enterprise stacks; Apache 2.0; less active.
• Amundsen (Lyft) — Apache 2.0; older OSS catalog; less active since DataHub overtook it.
• DataDocs — newer; lightweight; Apache 2.0.
• Castor / Atlan / Alation / Collibra — paid SaaS catalogs; enterprise.

Lineage standards & libraries

• ★ OpenLineage — vendor-neutral lineage spec + integrations for Airflow / Dagster / Spark / dbt / Flink. Apache 2.0. The default lineage layer; most catalogs ingest from it.
• ★ Marquez — reference OpenLineage backend; PostgreSQL store + UI. Apache 2.0.
• dbt manifest.json — column-level lineage that dbt itself emits; ingested by DataHub / OpenMetadata / Lightdash.
• SQLLineage (Python) — parse SQL files for table-level lineage; MIT.
• SQLGlot lineage — SQLGlot's lineage() API gives column-level lineage from arbitrary SQL; MIT.

Lakehouse-native / lakehouse-adjacent catalogs

• ★ Unity Catalog OSS (Databricks, 2024) — open-sourced catalog with Iceberg / Delta REST APIs; Apache 2.0. Watch — gaining traction outside Databricks.
• Apache Polaris (Snowflake, 2024) — Iceberg REST catalog; Apache 2.0; competitor to Unity Catalog OSS.
• Project Nessie — Iceberg-native catalog with Git-like branches over data; Apache 2.0.
• AWS Glue Data Catalog — paid; the AWS default; Iceberg/Hive table catalog.
• Hive Metastore (HMS) — the original Hadoop catalog; still common as a backend.
• Iceberg REST Catalog — the wire protocol; many of the above implement it.

Lightweight / docs-as-catalog

• dbt docs — dbt docs generate produces a static site with model lineage; free. Often "good enough" for small teams.
• SQLMesh's plan / lineage UI — built-in column lineage; see Data Transformation & Modeling.
• Lightdash — surfaces dbt-defined metrics + lineage in a BI UX; see BI & Dashboards.
• Notion / Confluence + a query-of-record table — the "we have 8 datasets" answer.

Patterns to know

• OpenLineage everywhere. Configure your orchestrator and warehouse jobs to emit OpenLineage; pick a catalog that ingests it.
• dbt is your ground truth for transforms. manifest.json powers most catalogs' transform lineage.
• Ownership tags as data. Catalog "owner" should sync from a system of record (HRIS / GitHub team), not free text.
• PII tagging at ingest. Tag at the source / staging layer; lineage propagates downstream.
• Avoid duplicate sources of truth. dbt + a catalog drifts fast unless you point the catalog at dbt.
• Catalogs only work if people use them. Embed search in IDE / Slack; nobody opens a separate web UI for a column lookup.

Pick this if…

• Default OSS catalog, broad connectors: DataHub.
• Easier ops, nice UX: OpenMetadata.
• dbt-only shop, small team: dbt docs + Lightdash.
• Iceberg / lakehouse: Unity Catalog OSS or Polaris.
• Just lineage, no UI: OpenLineage + Marquez.
• Git-flow over data: Nessie (with Iceberg).