Marquez Data Lineage: Self-Hosting Cost, Maintenance Status and Managed OpenLineage Alternatives

Marquez is the open source reference implementation of the OpenLineage API: a Java metadata service, a Postgres database and a React web UI that you run yourself. It is free under Apache 2.0, and as of August 2026 the last artifact it shipped was version 0.51.1, tagged on 27 March 2025. In that same period OpenLineage, the specification Marquez exists to serve, published 27 releases and reached 1.52.0. If you are choosing an OpenLineage backend right now, that gap is the single most important number in the decision.

This is not a hit piece on a good project. Marquez does what it says, it is a Linux Foundation AI & Data graduated project, and its own README still describes it as under active development. But teams evaluating it usually read the star count and the LF badge, assume a healthy release cadence, and only discover the real cadence after they have committed a quarter of engineering time to a rollout. Here are the numbers, pulled from the GitHub, PyPI and Docker Hub APIs on 22 August 2026, so you can make that call before rather than after.

What is Marquez and how does it relate to OpenLineage?

They are two different things and the distinction decides most of this evaluation.

OpenLineage is a specification. It defines the shape of a lineage event: a job, a run, the datasets consumed and produced, and facets that attach extra metadata to any of those. It ships client libraries and integrations for Apache Spark, Apache Airflow, Apache Flink, Apache Hive, dbt, Feast, Great Expectations, Trino and raw SQL. What it does not ship is a place to put the events. The spec is the envelope, not the mailbox.

Marquez is the mailbox. It is the reference backend: it accepts OpenLineage events over HTTP, stores them in Postgres, and draws the resulting graph in a browser. When a tutorial tells you to "send your Airflow lineage to OpenLineage", what it actually means is send it to a Marquez instance you stood up. Our companion piece on how the OpenLineage standard tracks Spark, dbt and Airflow lineage covers the event model itself in detail.

So the producer side and the consumer side of this stack are maintained by different groups of people, at very different rates. That turns out to matter a lot.

Is Marquez still maintained?

Yes, technically. It is not archived, the license is still Apache 2.0, and commits still land. But the release cadence stopped roughly seventeen months ago, and the project's own documentation points you at a build from October 2024.

Verified against the GitHub REST API, pypi.org and Docker Hub on 22 August 2026. Both projects are live and unarchived; the difference is cadence, not intent.

The detail that convinced us this is worth writing down is in Marquez's own README. Its compatibility table marks 0.50.0 as RECOMMENDED and everything newer as UNRELEASED. The project is telling you, in its own words, that the version it recommends you run is the one from October 2024. That is a more useful signal than any star count.

Meanwhile the producer side is in excellent health. Airflow's OpenLineage provider hit 2.20.0 on 8 August 2026. The Python client tracks the spec release for release. Whatever you decide about the backend, emitting OpenLineage events from your pipelines is a safe bet.

What does it cost to self-host Marquez?

There is no license fee. The cost is entirely in what you run and who keeps it running, and the README is refreshingly specific about the shape of it.

• Java 17 for the API service, built with Gradle, shipped as a fat jar or the published Docker image.
• PostgreSQL 14 as the metadata store. This is the piece that grows. Every run of every job writes events, and lineage history is exactly as long as your retention policy and disk allow.
• A separate web module for the UI, listening on port 3000, with the API on 5000 and an admin interface on 5001 exposing /healthcheck and /metrics.
• A Helm chart if you want it on Kubernetes, which most teams do once it stops being a demo.

Read the requirements next to the release cadence and the real bill becomes obvious. Pinning to a build from March 2025 means you own its dependency tree: the Java runtime, the Postgres major version, and every CVE that lands in either between now and whenever the next release ships. On a project releasing monthly, that work is somebody else's. Here it is yours.

There is one line in the README that belongs in your security review before anything else: "By default, the HTTP API does not require any form of authentication or authorization." Marquez is designed to sit inside a trusted network, and the lineage endpoint is wide open unless you put something in front of it. That is a reasonable default for a reference implementation and a genuinely bad one for an internet-reachable host, so budget for a reverse proxy, network policy or gateway as part of the deployment rather than as a follow-up ticket. Once it is running you have also taken on the uptime: pipelines that emit events to a dead collector fail quietly and leave holes in the graph you will not notice for weeks, so it is worth having something that checks that the endpoint is actually answering rather than trusting that it is.

None of this is exotic. It is a Java service, a database and a web app, and a competent platform engineer will have it up in an afternoon. The honest number is not the afternoon. It is the standing quarter-over-quarter maintenance on a component nobody on the data team wants to own.

What can you use instead of Marquez as an OpenLineage backend?

The good news about betting on a specification is that the specification has other consumers. If your pipelines already emit OpenLineage events, you can point them somewhere else without touching the producers. Several platforms document OpenLineage ingestion directly:

• Google Cloud Knowledge Catalog (the service formerly branded Dataplex) documents an OpenLineage integration for reporting lineage events into its own graph.
• Amazon SageMaker Unified Studio builds its lineage feature on OpenLineage and documents the event model to users directly.
• IBM Manta Data Lineage ships an OpenLineage scanner as one of its supported sources. We compare that platform in our Manta data lineage comparison.
• OpenMetadata has an OpenLineage pipeline connector, and it is an active project. Our OpenMetadata comparison covers the deployment footprint, which is heavier than Marquez.
• Astronomer documents the Airflow OpenLineage integration in depth and is where a lot of the practical Airflow guidance lives.

The trade-off is the familiar open-source one. Marquez is the only option on that list that is small, single-purpose and free. Everything else is either a cloud platform you are already paying for, or a full catalog with its own operational weight. We keep a maintenance check on the wider field in our review of open source data catalog tools, and DataHub is the other serious open-source option with real column-level lineage.

Do you actually need OpenLineage at all?

This is the question most evaluations skip, and for a lot of teams the answer is no.

OpenLineage is an instrumentation model. It gets accurate because your pipelines tell it what they did, which means every producer has to be instrumented, and anything that writes to your warehouse outside those producers is invisible. An analyst who builds a table with an ad hoc CREATE TABLE AS SELECT, a Fivetran connector nobody wired up, a stored procedure, a one-off backfill: none of those emit events, and none of them appear in the graph. The lineage is precise about what it sees and silent about what it does not.

The other route is to read the warehouse's query history and parse what actually ran. That catches everything that touched the data regardless of who or what issued it, at the cost of depending on SQL parsing rather than on the engine telling you directly. Datatrail takes this route: it connects read-only, parses query logs and the dbt graph into column-level lineage, and runs impact analysis so you see every downstream model, exposure and dashboard before a change ships. No collector to deploy, no events to instrument, nothing to keep patched.

Warehouses increasingly do a version of this natively too, with the caveats that come from being inside one platform. We wrote up the exact limits of the Snowflake version, including the one-year retention window and the pricing of its data quality checks, in our Snowflake Horizon Catalog comparison.

Marquez or a managed lineage tool: how to decide

The pattern we see most often: a team adopts OpenLineage for the producers because the standard is genuinely good and well maintained, then discovers that owning the collector is the part nobody budgeted for. Instrumenting is the easy half. Running the thing that receives the events, forever, is the half that shows up on someone's on-call rotation.

Is Marquez free?

Yes. Marquez is Apache 2.0 licensed with no commercial tier, no seat count and no vendor to call. The cost is a Java service, a Postgres instance you keep sized and backed up, a web app, an authentication layer the project does not provide, and the engineering hours to keep all of it current on a release cadence you do not control. That is a real number, and for a lot of teams it is larger than a subscription.

If you want to see how the whole field compares, including the managed platforms and the other open-source projects, start with our roundup of data lineage tools. If you would rather just see your own lineage graph without deploying anything, Datatrail connects read-only to your warehouse and builds it from your query history in minutes, with the price on the pricing page.