Marquez.
Founded 2018
Status · ● active
Verified · ● 2mo ago
The OpenLineage reference backend — vendor-neutral lineage events from Spark, Airflow, dbt, and Flink, stored and visualised.
Where it fits — and where it doesn't.
Data platform teams who want a vendor-neutral lineage substrate under existing pipeline tooling, especially Airflow plus Spark plus dbt shops where OpenLineage providers are already shipping events.
Strong fit when the operating principle is "open standard, no vendor lock-in" rather than "polished UI for business users." Also a defensible choice for organisations that already run a heavy catalog (Atlan, DataHub, OpenMetadata) and want lineage events flowing into both for redundancy or re-use, since OpenLineage is fundamentally a producer-consumer protocol — multiple backends can subscribe.
You need a polished business-user experience, glossary, ownership workflows, or a sales motion that comes with a quarterly business review.
Marquez is engineering-grade — the UI is functional, not glamorous, and the lineage you see is only as good as the OpenLineage emitters in your pipelines. Also avoid if you have heavy non-OpenLineage estates (mainframe, SAP, legacy ETL) — those won't show up in Marquez at all, and a scanner-driven product (IBM Manta, Cloudera Octopai) is the right shape there.
The honest scorecard.
- The reference implementation of OpenLineage — interoperability with the standard is its native shape, not a marketing claim
- Apache-2.0 with no enterprise-only features held back; what you self-host is what exists, full stop
- LF AI & Data graduated project — governance is institutional, not single-vendor
- Column-level lineage flowing through from the Spark integration (since Marquez 0.27 / OpenLineage 0.9)
- Active multi-vendor community — Astronomer, dbt Labs, and Microsoft contributors keep the project moving
- No managed offering exists. There is no Marquez Cloud — you self-host or you don't run it
- UI is engineering-grade. No business glossary, no ownership workflows, no governance approvals
- Lineage coverage equals OpenLineage coverage. If your pipeline doesn't emit OpenLineage events, Marquez sees nothing
- BI tool lineage is essentially absent — no native Looker, Tableau, or Power BI emitters in OpenLineage as of 2026
- Documentation and quickstart polish lags behind the OSS catalogs (DataHub, OpenMetadata)
What Marquez actually is.
What Marquez actually is
Marquez is the canonical place to send OpenLineage events when you don’t want a vendor. Pipelines emit OpenLineage events (Airflow via the official provider, Spark via the OpenLineage Spark agent, dbt via the OpenLineage dbt integration), Marquez consumes those events into a Postgres-backed graph, and a UI visualises the resulting lineage at table and column granularity. The defining technical fact is that Marquez is the reference backend — interop with the standard isn’t an integration, it’s the architecture.
Around that core, Marquez ships a basic asset and job search surface, historical run tracking, and a REST API. There is no glossary, no ownership workflow, no governance UI. That is the deliberate scope.
Where it fits against the alternatives
OpenLineage went from “interesting standard” in 2022 to LF AI graduated and the de facto lineage protocol by 2026, primarily on the strength of the Apache Airflow project itself maintaining the OpenLineage provider and dbt Labs shipping native emitters. Marquez is the canonical place to send those events when you don’t want a catalog vendor — but in 2026 most production deployments are sending OpenLineage events into atlan, datahub, or openmetadata instead, because those backends offer a richer surface (glossary, governance, search) on the same event stream.
The honest 2026 read: Marquez is the right answer when your operating principle is open-standards-no-vendor; otherwise the lineage events you produce are increasingly useful in a richer catalog backend, and you’re better served running Marquez alongside (or migrating events into) one of the catalogs.
On OpenLineage as a standard
OpenLineage’s adoption arc is the more interesting story than Marquez itself. By mid-2026 there are first-party emitters in Airflow, Spark, Flink, dbt, and a handful of warehouse-side producers. Consumer support spans Marquez, Atlan, DataHub Cloud, OpenMetadata (community work), and Microsoft Fabric (since 2024). For organisations choosing a lineage substrate today, the more durable bet is “we’ll emit OpenLineage events and pick the backend later” rather than “we’ll commit to one vendor’s proprietary lineage format.” Marquez is the obvious low-risk consumer to validate that bet.
How to evaluate it
The honest test is to stand up Marquez against your existing Airflow or dbt environment, enable the OpenLineage provider, and run a representative DAG. Look at: did the lineage materialise correctly, was the column-level granularity accurate, and is the UI sufficient for your team’s actual lineage queries (typically “what depends on this column” and “what produced this value”)? If the answer is yes, Marquez is the strongest no-vendor option. If you find yourself missing glossary, ownership, or steward workflows, that is the signal to evaluate one of the catalog backends as the OpenLineage consumer instead.
All capabilities by cluster.
Catalog & discovery
Secondary · strength 1/3Lineage & metadata
Primary · strength 3/3Where it plugs in.
Native warehouse support
Orchestrators & pipeline tools
The honest pricing breakdown.
Free tier Fully open source under Apache-2.0; no paid tier exists. Run cost is your own infrastructure (Marquez server plus Postgres).
Full Marquez pricing breakdown — model, cost factors, alternatives by price →
What it doesn't do.
A managed vocabulary of business terms ("Active Customer", "Recognized Revenue") with definitions, owners, and — critically — links to the physical assets that implement them. Without the linking layer a glossary is just a wiki. With it, you can answer "which dashboards use our official definition of Active Customer?" — the question governance teams actually care about.
PII Auto-Classification →Automatically identifies columns likely to contain personally identifiable information — email addresses, phone numbers, national IDs — through regex, name heuristics, or ML. Required for meaningful compliance workflows at scale. Quality varies: naive implementations produce heavy false-positive rates. Worth asking vendors about their accuracy benchmarks.
Reverse Impact Analysis →Given a downstream asset — typically a dashboard or a metric — traces backward to every upstream table, column, and pipeline it depends on. The inverse of forward impact analysis. Valuable for debugging ("this dashboard is wrong, what could have caused it?") and for establishing the blast radius of historical incidents.
Drill into one capability.
Other key features
If not Marquez, then what?
Common alternatives
Teams typically migrate to
See all 2 Marquez alternatives, scored and compared →Quick answers.
- Is Marquez open source?
- Yes. Marquez is open source under the Apache-2.0 license, and can be self-hosted at no license cost. A paid managed tier is also offered.
- How much does Marquez cost?
- Marquez publishes pricing, starting around $0 custom. A free tier is available: Fully open source under Apache-2.0; no paid tier exists. Run cost is your own infrastructure (Marquez server plus Postgres).
- How is Marquez deployed?
- Marquez is self-hosted — you run it in your own infrastructure.
More lineage & metadata tools
Provenance.
Last verified 2026·05·08 against vendor documentation and, where possible, hands-on trial. Spot something off? Send a correction →