300+ Tools CoveredSource Data Updated Weeklydates

Tool intelligence profile

Marquez

Open-source metadata service for data lineage

Visit Site →
Type
Data Catalog
Category
Data Quality
Pricing
Free (open source)
Deployment
Cloud or self-hosted
Last updatedSeptember 21, 2026Open Source

Editor's Take

We recommend Marquez for data platform teams that already emit OpenLineage events from Airflow, Spark, or dbt and can dedicate at least one engineer to running a self-hosted Postgres-backed service — as the OpenLineage reference implementation it offers the most direct ingestion path, and with a $0 license the real cost is operational. We suggest teams wanting a full catalog with built-in quality tests, business glossary, and access controls evaluate DataHub or OpenMetadata instead, since Marquez scopes itself deliberately to lineage and run metadata rather than quality enforcement. One evidence gap worth naming: the available signals here are repository activity and foundation stewardship, which indicate active maintenance but say nothing about production adoption at enterprise scale, so ask the community for named reference deployments before standardizing on it.

— Egor Burlakov, Editor

Evaluate Marquez

Top Alternatives
Substitutes, and when to pick them
Best Data Catalogs
Ranked by public evidence
Data Catalogs landscape
9 published products in this market
Browse Data Quality
Every published tool in the category
Stack Recommender
Build a stack around Marquez

Popular comparisons

vs Atlan
Head-to-head comparison
vs Elementary
Head-to-head comparison
vs Great Expectations
Head-to-head comparison
vs Soda
Head-to-head comparison
See all 5 Marquez comparisons
vs Monte Carlo
Head-to-head comparison

Marquez: product and architecture

The short verdict from this Marquez review: if your organization has standardized on OpenLineage and wants a self-hosted lineage backend you fully control, Marquez is the reference implementation and the obvious default — and if you want an out-of-the-box governance platform with business glossaries, access workflows, and a vendor SLA, it is the wrong tool and you will be disappointed. Marquez is not a data catalog and, despite being filed under data-quality taxonomies, it is not a data quality or testing framework either. It is a metadata service: a Java API server with a Postgres-backed store and a web UI, published under Apache-2.0, that ingests OpenLineage events and renders them as a lineage graph. That narrowness is the product's greatest strength and the single biggest reason teams outgrow it.

Overview

Marquez (marquezproject.ai) describes itself as an open-source metadata service for collecting, aggregating, and visualizing data lineage, and the GitHub repository summarizes the same scope: "Collect, aggregate, and visualize a data ecosystem's metadata." The project carries 2,275 GitHub stars, is written primarily in Java, and is licensed Apache-2.0 — a permissive license with no copyleft obligations, which matters if you plan to fork it or embed it inside an internal platform.

The architectural center of gravity is the relationship with OpenLineage. Marquez is the reference implementation of the OpenLineage specification, and its metadata server exposes an OpenLineage-compatible endpoint for real-time collection from running jobs and applications. The practical consequence is that Marquez inherits the entire OpenLineage integration surface without writing bespoke connectors: Apache Airflow, Apache Spark, Apache Flink, dbt, and Dagster all emit events Marquez can consume as-is.

The second half of the product is the web UI, which renders a visual map of interdependencies across your ecosystem. It lets you browse stored metadata, inspect the inputs and outputs of each job, trace the lineage of an individual dataset, and review performance metrics and execution details attached to specific runs. That run-level detail is what separates Marquez from a static diagram — lineage here is a byproduct of actual execution, not a hand-maintained document.

One signal deserves candid treatment. The repository's most recent push is dated 2026-09-07, so development activity is current, but the latest tagged release is 0.50.0 from 2024-10-24. Nearly two years between tagged releases means teams that pin to published artifacts are running considerably older code than what is on the main branch. We treat the 2,275 stars and the topic tags (data-dictionary, data-discovery, data-ecosystem-metadata, data-governance, data-lineage, data-ops, data-provenance) as public adoption and positioning signals, not as evidence of production deployment counts, which the project does not publish.

Key Features and Architecture

Marquez is deliberately a small number of components doing one job well. The following are the pieces that actually determine whether it fits your stack.

  • OpenLineage-compatible HTTP ingestion endpoint. The metadata server accepts OpenLineage events over HTTP in real time from running jobs, rather than scraping schedulers or parsing logs after the fact. Because the payload contract is the OpenLineage spec rather than a Marquez-proprietary format, the emitting side of your pipeline is not coupled to Marquez — you can redirect the same events to a different OpenLineage consumer later without touching pipeline code.
  • Reference implementation status. Marquez is the reference implementation of OpenLineage, which is a technical statement, not a marketing one: it means the API server already works with every integration the OpenLineage community has built, including Apache Airflow, Apache Spark, Apache Flink, dbt, and Dagster. For a team already running Airflow and dbt, instrumentation is a matter of configuring the existing OpenLineage integration to point at the Marquez endpoint.
  • Job/run/dataset metadata model. Marquez receives, processes, and stores lineage metadata using the OpenLineage standard, which models the world as jobs, runs, and datasets rather than as free-form assets. Storage is relational (Postgres), which means lineage is queryable with SQL if you need reporting that the UI does not provide — useful for compliance extracts and for building your own internal views.
  • Run-level execution and performance metadata. Beyond graph edges, the UI surfaces execution details and performance metrics per run. This is what makes Marquez usable for incident work: you can look at a dataset, walk upstream, and see which specific run produced the version you are questioning, instead of only seeing that a dependency exists in the abstract.
  • Visual lineage graph with dataset-level tracing. The web UI renders complex interdependencies as a navigable map, with the ability to browse inputs and outputs per job and trace lineage for an individual dataset. It is a purpose-built lineage explorer rather than a general search-first catalog experience.
  • Self-hosted Java service under Apache-2.0. The primary language is Java, so operating it means running a JVM service alongside a Postgres database. The Apache-2.0 license imposes no share-alike requirement on modifications, which is why Marquez frequently shows up embedded inside larger internal data platforms rather than as a standalone end-user product.

The trade-off in this design is explicit: everything Marquez knows, it knows because something emitted an OpenLineage event. There is no crawler that will discover your warehouse for you.

Ideal Use Cases

Platform teams standardizing on OpenLineage. The clearest fit is a data platform group of roughly three to ten engineers that runs Airflow or Dagster for orchestration, Spark or Flink for processing, and dbt for transformation, and wants one lineage backend for all of it. Because all five of those tools are covered by OpenLineage integrations Marquez already supports, the work is instrumentation and deployment rather than connector development. We recommend Marquez for exactly this team profile — it is the lowest-friction way to turn an existing OpenLineage commitment into a working graph.

Incident triage and impact analysis in mid-size engineering organizations. For a company running hundreds to low thousands of scheduled jobs, the recurring question during an incident is "what else consumed this table before we caught the problem?" Marquez answers that by letting an on-call engineer trace a dataset's lineage and inspect the run that produced it, including execution details. Analytics engineers get the mirror-image benefit: before deprecating a model, walk downstream and see what actually reads it, as observed from run history rather than from tribal knowledge.

Regulated environments that cannot send metadata to a vendor. Financial services, healthcare, and public sector teams often cannot route pipeline metadata through a third-party SaaS control plane. A self-hosted Apache-2.0 Java service with a Postgres store keeps all lineage inside your own network boundary, and the permissive license means legal review is usually straightforward. Data provenance and data-governance are explicit topics on the repository, and the SQL-queryable store makes audit extracts tractable.

Embedding lineage inside an internal platform. Some teams do not want the Marquez UI at all; they want a lineage API behind their own portal. Apache-2.0 plus a documented ingestion contract makes that viable.

Don't use this if you need a business-facing data catalog — glossary terms, ownership workflows, certification badges, column-level policy enforcement, and non-technical search. Marquez is a lineage service, not a governance suite, and bolting those capabilities on top is a multi-quarter internal project. Equally, don't use this if you have no OpenLineage emitters and no appetite to add them, or if you have no one on staff who can operate a JVM service and a Postgres database in production.

Pricing and Licensing

Pricing details are not published in the supplied source data.

What is published is the licensing and distribution model, and it is unambiguous: Marquez is open source under Apache-2.0, distributed free of licensing charges. That model determines the cost structure more than any price list would. There are no per-seat fees, so the number of engineers, analysts, or stakeholders browsing the lineage graph has no effect on cost — a meaningful difference from commercial catalog platforms, where widening access to non-technical users is the main driver of contract growth. There is likewise no usage-based metering on events ingested or datasets tracked, so a team that instruments every Airflow DAG and every dbt model pays nothing incremental for the additional metadata volume.

The cost moves entirely to total cost of ownership on your side. You are responsible for running a Java service and a Postgres instance: compute, storage, backups, upgrades, TLS termination, authentication, and monitoring. Lineage storage grows with run volume rather than with data volume — a pipeline processing terabytes produces the same event footprint as one processing megabytes — so the database sizing question is "how many runs per day, retained for how long," and retention policy is the main lever you control. Budget for the engineering time to answer that, plus periodic Postgres maintenance.

Apache-2.0 carries no copyleft obligation, so modifications and internal embedding require no source disclosure, and there is no vendor lock-in risk on the license itself. The genuine risks are operational rather than contractual. There is no commercial SLA in the published model, which means production incidents are your team's to resolve, and the release cadence is yours to absorb: with the latest tagged release at 0.50.0 (2024-10-24) and pushes continuing through 2026-09-07, teams must decide whether to run tagged artifacts or build from a newer commit, and own the consequences either way. For organizations that require contractual support, that gap is the decisive cost factor, and it is not one money can close within this model.

Strengths & Trade-offs

Pros

  • Zero connector work for five major engines. Because Marquez is the OpenLineage reference implementation, Airflow, Spark, Flink, dbt, and Dagster metadata flows in through community-maintained integrations rather than code you write and maintain. This is the single highest-leverage property of the tool.
  • Lineage is derived from actual runs, not declarations. The UI exposes per-job inputs and outputs plus execution details and performance metrics, so the graph reflects what executed rather than what someone documented. Stale lineage is a common failure mode elsewhere; Marquez structurally avoids it for instrumented pipelines.
  • No lock-in at either end. Apache-2.0 on the code, OpenLineage on the wire. If you replace Marquez, your emitters keep working; if you fork Marquez, the license permits it without source disclosure obligations.
  • Relational, queryable metadata store. Lineage in Postgres means audit reports, custom dashboards, and bulk extracts are SQL problems, not API-pagination problems.
  • Cost scales with runs, not with seats or data volume. Onboarding the whole analytics org to the lineage UI adds no licensing cost.

Cons

  • Nothing is discovered automatically. Any system that does not emit OpenLineage events is invisible. Hand-rolled Python scripts, stored procedures, BI-tool transformations, and ELT vendors without OpenLineage support leave holes in the graph, and a lineage graph with silent gaps is dangerous precisely because it looks complete.
  • The tagged release cadence is a real operational concern. Release 0.50.0 dates to 2024-10-24 while the repository was pushed as recently as 2026-09-07. Teams with change-control policies that require versioned artifacts are choosing between old tags and unreleased commits.
  • It is not a catalog, and the category label is misleading. Despite data-discovery, data-dictionary, and data-governance appearing as repository topics, Marquez does not deliver glossary management, ownership workflows, or policy enforcement, and it does not perform data quality testing at all. Buyers who read "data-quality" as the category will mis-scope the project.
  • Java plus Postgres is an operational commitment. Small analytics teams without platform engineering support will spend more time on deployment, upgrades, and auth integration than they expect, and there is no commercial SLA to fall back on.
  • Adoption evidence is limited to public proxies. 2,275 GitHub stars indicate visible community interest; the project publishes no enterprise deployment counts, uptime data, or reference customer numbers, so scale evidence has to come from your own pilot.

Alternatives to Marquez

The reviewed substitutes for Marquez among the data catalogs, and what would make each one the better answer.

Direct alternatives

Reviewed substitutes: products bought for the same job, where a team picks one.

Atlan
Two data catalogs covering discovery, lineage, glossary and governance for the same estate. Vendors publish direct comparisons and independent 2026 guides rank them together, and an organisation buys one.Applies to: Choosing the catalog that will hold discovery, lineage and governance.

Other approaches

A different approach to the same problem. Each substitutes only for the workload named beside it.

Elementary
Choose Elementary if your stack is built around dbt and you want lineage plus quality monitoring tightly integrated with your transformation layer.Applies to: Whether discovery and reliability need two products, or one platform can carry both.

Related technologies

Normally used together rather than chosen between, so these are not alternatives.

Great Expectations
Choose Great Expectations if your primary concern is validating data correctness rather than tracking lineage across pipelines.Applies to: Whether a data catalog removes the need for a separate checks tool, or reports what it found.
Soda
A validation framework defines and runs checks; a catalog stores and displays the results beside lineage, ownership and glossary. Catalogs integrate the check tools rather than replacing them, so the pair is deployed together and the reader's question is which job each one does.Applies to: Whether a data catalog removes the need for a separate checks tool, or reports what it found.
Monte Carlo
Not substitutes. Monte Carlo detects data incidents with ML-driven anomaly detection; Marquez is an open-standard lineage collection service. Lineage is an input to incident triage, not a replacement for detecting the incident. Approved by derive:R2-head-to-head-verdict from the comparison page's own verdict.Applies to: Marquez supplies the lineage Monte Carlo uses to trace an incident to its source.

Head to head

See detailed alternatives analysis

Marquez is an open-source metadata service built specifically for collecting, aggregating, and visualizing data lineage. As the reference implementation of OpenLineage, it provides a standardized way to track data dependencies across pipelines. If you are evaluating Marquez alternatives, the right choice depends on whether you need a pure lineage tool, a broader metadata catalog, or a full data observability platform.

Top Alternatives Overview

DataHub is the leading open-source metadata platform, offering data discovery, observability, and federated governance under an Apache 2.0 license. Unlike Marquez's narrow focus on lineage, DataHub provides a full data catalog with search, tagging, ownership tracking, and automated metadata ingestion from dozens of sources. It also offers a managed cloud version with enterprise features like saved searches and email alerts. Choose DataHub if you need a comprehensive metadata platform that goes well beyond lineage tracking.

OpenMetadata is a unified metadata platform with 14,000+ GitHub stars and 120+ native connectors covering databases, dashboards, pipelines, and ML models. Built by the founders of Apache Hadoop, Apache Atlas, and Uber Databook, it combines data discovery, quality, observability, and governance in a single platform with a schema-first API architecture. It reports over 3,000 enterprise deployments and 370+ code contributors. Choose OpenMetadata if you want an all-in-one open-source platform that replaces multiple point solutions including lineage, cataloging, and data quality.

Great Expectations is the open-source standard for data quality testing with 11,000+ GitHub stars, a Python-based framework, and a newer GX Cloud managed service. It focuses on codified data expectations rather than lineage, letting teams write explicit validation rules that double as living documentation. The framework integrates with CI/CD pipelines, orchestration tools, and can auto-generate tests using its ExpectAI feature. Choose Great Expectations if your primary concern is validating data correctness rather than tracking lineage across pipelines.

Elementary is a dbt-native data observability platform with column-level lineage, automated anomaly detection, and incident management. Its cloud plans start at a Scale tier with up to 10 editor seats and 5,000 tables, with Enterprise and Unlimited tiers adding SSO, RBAC, and dedicated support. Elementary manages all configurations in dbt code, enabling version control and code review for observability settings. Choose Elementary if your stack is built around dbt and you want lineage plus quality monitoring tightly integrated with your transformation layer.

Collibra is an enterprise-grade data governance platform headquartered in Brussels, offering unified governance for data and AI. It provides data cataloging, policy management, compliance automation, and lineage tracking through a cloud-based platform trusted by regulated organizations. Pricing requires contacting sales, reflecting its enterprise positioning. Choose Collibra if you are a large regulated enterprise that needs compliance-driven governance, audit trails, and business glossary management alongside lineage.

Castor (CastorDoc) is an automated data discovery and catalog tool that provides Google-like search for finding tables and datasets across your organization. It focuses on making data assets discoverable and well-documented, with automated metadata enrichment and contextual documentation. Choose Castor if your biggest pain point is data discovery and you want a user-friendly catalog that non-technical stakeholders can actually navigate.

Architecture and Approach Comparison

Marquez takes a deliberately narrow architectural approach: it is a real-time metadata server with an OpenLineage-compatible API endpoint that collects lineage events from running jobs. Written in Java, it stores lineage metadata in PostgreSQL and exposes it through a REST API and web UI. This simplicity is its strength for teams that only need lineage, but it means you must bolt on separate tools for data quality, cataloging, and governance.

DataHub and OpenMetadata take the opposite approach with extensible metadata graphs that model relationships between datasets, pipelines, dashboards, users, and policies. OpenMetadata uses a four-component architecture designed for simple deployment and operates with a TypeScript frontend and Java backend. DataHub uses a graph-based metadata store (built on Apache Kafka and Elasticsearch) that supports real-time metadata changes and programmatic access through its GraphQL API.

Great Expectations and Elementary focus on the data quality layer rather than metadata management. Great Expectations runs validation checkpoints directly inside your Python pipelines, while Elementary operates as a dbt package that executes within your data warehouse. Neither replaces Marquez's lineage capabilities directly, but both provide the quality monitoring that Marquez lacks. Elementary's column-level lineage feature does overlap with Marquez, though it derives lineage from dbt's DAG rather than from OpenLineage events.

Pricing Comparison

ToolModelStarting PriceSelf-Hosted Option
MarquezOpen SourceFreeYes (only option)
DataHubFreemiumFree (OSS) / Enterprise contact salesYes
OpenMetadataOpen SourceFreeYes (also free SaaS sandbox)
Great ExpectationsOpen Source + CloudFree (GX Core) / GX Cloud tiersYes
ElementaryFreemiumScale tier (contact sales) / Enterprise tierYes (dbt package)
CollibraEnterpriseContact salesNo (cloud-based)
CastorEnterpriseContact salesNo

Marquez, DataHub, and OpenMetadata all offer fully free self-hosted deployments under Apache 2.0 licenses. Great Expectations provides its Python framework (GX Core) free and open-source, with GX Cloud available in Developer, Team, and Enterprise tiers. Elementary's open-source dbt package is free, but its cloud platform uses seat-based and table-count-based pricing across Scale, Enterprise, and Unlimited tiers. Collibra and Castor are enterprise-only with opaque pricing that typically starts in the tens of thousands annually.

When to Consider Switching

Switch from Marquez when your lineage needs expand into broader metadata management. If your team spends significant time manually connecting lineage data to catalog entries, quality checks, and governance policies, a unified platform like OpenMetadata or DataHub eliminates that integration burden. Marquez has 2,000+ GitHub stars compared to OpenMetadata's 11,200+ and Great Expectations' 11,400+, which reflects a focused community producing a compact set of integrations and measured feature development.

Consider switching if you need automated data quality monitoring. Marquez tells you where data flows but not whether it is correct. Teams that need anomaly detection, freshness monitoring, or validation rules will find themselves running Marquez alongside Great Expectations or Elementary anyway. At that point, a platform like OpenMetadata that bundles quality and lineage together reduces operational overhead.

If your organization is growing beyond a single data engineering team, Marquez's lack of role-based access control, ownership management, and collaboration features becomes a real limitation. DataHub and OpenMetadata offer fine-grained permissions, data ownership assignment, and team collaboration workflows that Marquez simply does not provide.

Stick with Marquez if you are deeply invested in the OpenLineage standard and need a lightweight, single-purpose lineage service. Its role as the OpenLineage reference implementation means it has first-class support for Airflow, Spark, Flink, dbt, and Dagster integrations without the complexity of a full metadata platform.

Migration Considerations

Migrating from Marquez to DataHub or OpenMetadata is straightforward because all three use similar metadata models and support OpenLineage events. DataHub can ingest OpenLineage events directly, so existing pipeline integrations that emit OpenLineage to Marquez can be redirected with minimal changes. OpenMetadata supports 120+ native connectors and can re-crawl your data sources to rebuild lineage independently of Marquez's stored data.

The learning curve varies significantly. Moving to DataHub or OpenMetadata means adopting a much larger system with more concepts to understand: data domains, glossaries, policies, and user management. Teams accustomed to Marquez's focused lineage API should expect a 2-4 week ramp-up period for the broader platforms. Moving to Great Expectations or Elementary is a different kind of migration entirely, as these tools complement rather than replace lineage and focus on validation and monitoring instead.

Data format compatibility is generally good across the open-source options. Marquez stores metadata in PostgreSQL, and its API responses follow the OpenLineage spec. Export your lineage graph through the Marquez REST API before migration, then use the target platform's ingestion framework to rebuild it. For teams running Airflow or Spark with OpenLineage integrations, the migration mostly involves changing the target endpoint URL in your OpenLineage configuration from Marquez to the new platform's compatible receiver.

Public signals

About these signals

Verified factual signals from public sources. They indicate observable activity or interest, not total adoption, product quality, or cost.

0 GitHub commits 90d2.3k GitHub stars0 vulnerabilities across 1 packageOpenSSF score 4.0/10

See all signals from 5 sources
Source
Signals
Last updated
GitHub
Commits 90d:0Stars:2.3k↑7
September 21, 2026
Docker Hub
Pulls:1.1M↑9.7k
September 21, 2026
PyPI
Weekly downloads:84↓19
September 21, 2026
OSV
Package vulnerabilities:0 vulnerabilitiesacross 1 package

PyPI · marquez-python@0.50.0

September 21, 2026
OpenSSF
Security score:4.0/10

github.com/MarquezProject/marquez

September 21, 2026

Frequently asked questions

What is Marquez?

Marquez is an open-source metadata service for data lineage, designed to help organizations understand and manage their data across various systems.

How much does Marquez cost?

Marquez is an open-source metadata service licensed under Apache-2.0. The supplied evidence does not list public pricing, packages, or any sales-contact requirement, so it cannot establish a paid pricing model or costs.

Is Marquez better than Apache Atlas?

While both Marquez and Apache Atlas are data-lineage tools, Marquez is specifically designed to handle large-scale metadata management and provide real-time insights. However, the choice between the two ultimately depends on your organization's specific needs and infrastructure.

Is Marquez suitable for small businesses?

Marquez is primarily designed for enterprise-level organizations due to its complex metadata management capabilities and custom pricing model. It may not be the best fit for smaller businesses with simpler data requirements.

Can I use Marquez with cloud-based storage systems?

Yes, Marquez supports integration with various cloud-based storage systems, allowing you to manage metadata across multiple platforms and environments.

Related Data Catalogs

Other data catalogs in the catalog. Same kind of product, not a substitution recommendation.

Data Quality

Collibra

Achieve Data Confidence™ and scale AI from pilot to production. Collibra offers unified governance for data and AI, trusted by regulated organizations.

View tool profile
Data Quality

Select Star

Select Star is a modern data governance platform that gets your data AI-ready. Automated data catalog, lineage, and semantic models built on your existing data.

View tool profile
Data Quality

OpenMetadata

OpenMetadata is the #1 open source data catalog tool with the all-in-one platform for data discovery, quality, governance, collaboration & more. Join our community to stay updated.

View tool profile
View all Data Catalogs
← Back to all tools