Marquez

Editor’s note: This Marquez review evaluates documented workflows, technical specifications, and implementation details, with an emphasis on engineering fit and operating responsibility.

Quick verdict: I recommend Marquez for engineering teams that want a self-hosted OpenLineage backend for investigating pipeline dependencies and run history. Its appeal is focused lineage functionality without a software subscription, but you take responsibility for hosting, security, and the quality of incoming metadata. I would shortlist DataHub or OpenMetadata first for a broader governance program.

Key Takeaways

• $0 software license: Marquez is Apache 2.0 licensed, but infrastructure and administration remain separate costs.
• Operational lineage is the focus: Jobs, runs, and datasets provide context for troubleshooting connected pipelines.
• Column lineage has a UI: Field-level visualization is supported, alongside API access.
• Coverage depends on instrumentation: Missing events or field mappings leave gaps in the graph.
• Production security needs attention: The default HTTP API requires neither authentication nor authorization.

Marquez belongs among catalogs and governance tools, but I see it primarily as engineering metadata infrastructure, not a complete governance suite. Search and tags give it catalog functionality; its stronger buying argument is connecting what ran with what that work consumed and produced.

In this review, I weigh the license economics, documented setup journey, lineage coverage, and maintenance burden against DataHub, OpenMetadata, and Amundsen. My focus is whether your team can keep this service useful as pipelines change.

Marquez Pros and Cons

Marquez’s strongest features and biggest obligations come from the same design choice: it is infrastructure your engineering team owns.

I like the focused scope for platform engineers who already understand their orchestration stack. My hesitation is organizational: a useful graph can become a misleading reference if nobody owns event coverage after the initial rollout. The deployment owner also needs someone accountable for metadata coverage.

Marquez Pricing: Free Software, Real Operating Costs

Marquez pricing starts at $0 for the software license; production operating costs are separate. The distribution evaluated here is the Apache 2.0 open-source project, rather than a ladder of Free, Pro, and Enterprise subscriptions.

• Self-hosted open source: $0 software license. Best suited to engineering-led teams prepared to run the application and maintain its integrations.

Edition	Software license cost	Deployment	Separate responsibilities
Marquez open source	$0, Apache 2.0	Self-hosted	Hosting, PostgreSQL, backups, security, integration work, upgrades

That distinction matters when comparing Marquez with a managed product. A subscription line may disappear from the budget, but the service still consumes resources and engineering attention. Calling the whole deployment free would hide those recurring costs.

The principal cost drivers are practical:

• Application hosting: The API and web interface need an operating environment.
• Database operations: PostgreSQL needs persistent storage and a recovery strategy.
• Instrumentation: Pipelines need compatible emitters and consistent metadata identities.
• Maintenance: Application changes and integration upgrades need an accountable owner.
• Access controls: Production exposure needs a security boundary beyond the default API.

For an established platform team, some of that work may fit existing infrastructure practices. For a small analytics team without an infrastructure owner, it may create a new operational commitment. The same license can therefore represent very different value to two buyers.

My budget would cover the full lifecycle, including maintenance after installation. Getting the first graph populated is one milestone; keeping it representative as pipelines change is the recurring job. An inexpensive deployment that nobody maintains is not a bargain.

Is Marquez Good Value for Money?

My value judgment depends on the work Marquez replaces:

• Good value for lineage-first teams: Existing OpenLineage instrumentation makes the backend a natural candidate.
• Conditional value for new adopters: Instrumentation work may matter more than the application deployment.
• Weaker fit for broad governance: Building glossary and stewardship workflows around a narrower tool can distract from the original saving.

DataHub offers separate self-hosted and managed Cloud options, but that does not establish either as cheaper. The useful comparison is operating responsibility, not license price alone.

Reviewer’s Notes: I recommend a small self-hosted pilot using the $0-license edition for an engineer-owned platform team. Keep the initial scope to one meaningful pipeline rather than treating the whole estate as the starting requirement.

Getting Started With Marquez

The documented starting point is a Docker-based deployment, followed by sample metadata and then real event ingestion. I like that progression because it separates learning the metadata model from configuring an actual pipeline.

1. Prepare the local deployment. Install Docker and Compose, clone the Marquez repository, and work from its root directory. The startup script supports image tags, so the environment can use an explicitly chosen version instead of relying on a moving default.

2. Start with sample metadata. The quickstart command is ./docker/up.sh --seed. It starts the supporting services and seeds an example that makes the graph navigable before a real pipeline is connected.

3. Explore the example relationship. Open the web interface at localhost:3000, search for etl_delivery_7_days, and inspect its connection to public.delivery_7_days. The documented journey moves from the job and its run history to the output dataset’s schema and description.

4. Introduce real pipeline events. An OpenLineage producer supplies the metadata Marquez stores. This is the transition from a working demonstration to useful visibility into your own environment.

Three concepts make that interface easier to understand:

• Job: A named piece of processing work, such as an ETL task.
• Run: A particular execution of that job, with its own identity and state.
• Dataset: An input or output, such as a database table.

A namespace helps identify which environment or system a named object belongs to. I recommend deciding namespace conventions early, particularly where development and production use similar table names. Otherwise, a technically successful ingestion setup can still produce confusing identities.

The default Docker ports are 3000 for the UI, 5000 for the API, and 5001 for administration. A documented macOS port conflict has an API-port workaround using --api-port 9000. Source-based deployment has different defaults, so keep its connection settings separate from the Docker quickstart.

The basic event sequence is straightforward: a producer sends a START event, then a COMPLETE event for the same run identity. Those events describe the job and its input/output relationships. Correct identity matters because separate messages need to represent the same execution.

For Airflow, the documented route uses apache-airflow-providers-openlineage, an HTTP transport targeting api/v1/lineage, and a configured namespace. The host and port depend on deployment. In particular, localhost inside a container refers to that container, not automatically to the machine hosting Marquez.

Sample data does not establish real coverage. My preferred first real workflow is a pipeline with recognizable inputs and a useful downstream output. That gives the rollout a concrete purpose, such as understanding how a reporting table gets built, rather than merely accumulating nodes.

That initial scope should also be understandable to someone other than its author. A graph that only one engineer can interpret has not yet become shared operational infrastructure.

Tracing Jobs, Runs, and Datasets

Marquez is most compelling when the question is “What happened upstream?” rather than “Where is the approved definition of revenue?” Its model connects processing activity with the datasets that activity touches.

Consider a hypothetical delivery report that has stopped updating. The downstream table is the symptom, but the relevant failure could sit in an earlier pipeline. Lineage relationships provide a route back through contributing jobs instead of leaving the investigation anchored to the final table.

The useful context comes from several layers:

• Dependency relationships: Upstream and downstream connections show how represented jobs and datasets relate.
• Run information: Status and timing help distinguish completed work from processing still in progress.
• Dataset history: Versioned metadata can preserve schema changes associated with recorded activity.

I see the combination as more useful than a static dependency diagram. A connection explains why a job matters; execution context helps explain where an engineer should look next. It does not establish the root cause on its own.

Marquez stores metadata, not backup copies of dataset contents. An immutable dataset version records metadata history, not a recoverable snapshot of every row. That boundary is important when someone expects lineage to answer exactly what a previous report contained.

The REST API makes the stored information available outside the interface. A platform team could use lineage and run metadata as inputs to a custom backfill workflow, for example. The orchestration or remediation would still happen through additional code or another system.

Release 0.50.0 also adds a Data Observability dashboard with event statistics covering 24 hours and the past seven days. I regard those summaries as visibility into metadata activity, not proof of automatic anomaly detection or a standalone data-quality testing engine.

I value the investigation context here, while leaving diagnosis to the engineer. DataHub’s explicit glossary model is more relevant when the main dispute concerns the business meaning of a metric. Marquez’s job/run model is the better reason to shortlist it when engineers need to follow processing relationships.

Column Lineage and OpenLineage Integrations

Marquez supports column-level lineage in the web UI. It is not limited to table-level graphs, and treating field-level visualization as absent would misrepresent the current implementation.

The current column-lineage implementation represents datasets and columns, with zoom and adjustable traversal depth. Its dataset panel can also expose raw facet data and offer a download for oversized payloads. I like that technical inspection route because a puzzling graph sometimes needs an explanation at the event level.

The important qualification is that field mappings must reach the backend. The OpenLineage columnLineage facet identifies the input fields contributing to each output field. Marquez cannot reliably display a detailed dependency that the producer never supplied.

I separate coverage into three questions:

• Event coverage: Does the pipeline emit the relevant processing activity?
• Dataset coverage: Do those events identify the correct inputs and outputs?
• Column coverage: Do they include the field mappings needed for finer detail?

A positive answer to the first does not guarantee the other two. That is why I would not choose Marquez based on an integration logo count or assume every supported operator produces equivalent metadata.

OpenLineage supplies the shared event standard and collection integrations. Marquez receives, stores, and visualizes the resulting metadata. Airflow provider compatibility therefore belongs to the integration decision, not simply to the choice of backend.

Consistent names also matter across producers. If two emitters describe the same physical table using different dataset identities, the resulting metadata may not join into the graph an engineer expects. Naming conventions are part of the implementation, not cosmetic cleanup.

The current column API has a specific historical-query limit: it supports historical upstream lineage, but rejects a versioned node combined with withDownstream=true. Historical downstream impact graphs fall outside that supported query.

My broader judgment is favorable to the open protocol. It can reduce dependence on one collection format if a team later changes backends. That is not a guarantee of effortless historical migration, and newer transformation details still need compatibility with the deployed producer and Marquez versions.

Self-Hosting, Security, and Maintenance

The default API has no authentication or authorization. That is the first production concern I would raise, ahead of graph styling or deployment convenience.

A client may support sending a bearer API key, but a request header does not create server-side enforcement. The deployment needs an access boundary appropriate to the people and systems allowed to read or submit metadata.

I treat this metadata as potentially sensitive. Table names and field names can reveal business structure even without exposing table contents. Restricting access belongs in the deployment plan, even when the service stores no underlying table contents.

The architecture includes an API, a web UI, and PostgreSQL for metadata storage. Docker Compose provides a starting configuration with persistent database storage; deployment documentation also describes Helm charts for Kubernetes. Those are deployment mechanisms, not substitutes for operating procedures.

The responsibilities I would assign before production are:

• Access ownership: Define how users and event producers reach the service.
• Recovery ownership: Maintain database backups and a workable restoration process.
• Capacity ownership: Plan for event history, storage growth, and retention requirements.
• Service ownership: Monitor the application and database rather than relying on the graph alone.
• Upgrade ownership: Keep application and emitter changes coordinated.

Retention deserves deliberate planning because historical context is part of the buying argument. Keeping more history may improve investigation context, but it also increases the database burden. Any retention commitment needs to account for the intended event volume and available storage.

Release choice needs attention too. As checked on October 14, 2026, the latest published GitHub release was 0.50.0, published October 24, 2024. That date does not establish abandonment, but it makes the distinction between a released artifact and current main-branch code consequential.

My recommendation is to pin application and integration versions together as an intentional combination. A capability visible in current source should not automatically be assumed to exist identically in an older deployed image.

I consider these obligations reasonable for a staffed platform team. For a team seeking a turnkey catalog with business governance workflows, DataHub or OpenMetadata deserves an earlier look. Broader functionality does not eliminate self-hosting work, but it may better match the organizational problem.

How Does Marquez Compare With Alternatives?

I compare Marquez alternatives by the primary question users need answered. These three offer useful starting points for different catalog requirements.

• DataHub: My stronger starting point for governed business terminology. Its glossary model includes business definitions and parent glossary relationships. It also distinguishes self-hosted open source from managed Cloud, which matters if operating responsibility is part of the purchase decision. The DataHub review covers that alternative.

• OpenMetadata: My shortlist choice when cataloging and data-quality test management belong in the same project. Its models represent glossary ownership and reviewers alongside test definitions, results, and incident fields. That is a broader foundation than using run metadata alone to investigate an issue.

• Amundsen: My discovery-focused alternative when the recurring problem is finding datasets and their owners. Its documented scope includes tables, dashboards, ML features, and people. The architecture separates services, so choosing discovery over operational lineage does not remove infrastructure responsibility.

Product	Main buying emphasis	Relevant documented capability	Main consideration
Marquez	Pipeline investigation	Jobs, runs, dataset history, column lineage	Coverage depends on emitted metadata
DataHub	Catalog and business terminology	Dedicated glossary model	Distinguish OSS from managed Cloud
OpenMetadata	Catalog and quality management	Glossary stewardship and test-case models	Broader implementation scope
Amundsen	Data discovery	Searchable data and people entities	Multiple services to operate

These are differences in emphasis, not claims that each product owns an exclusive feature category. Marquez has search and tags; the alternatives also cover metadata beyond the narrow examples above.

For a platform team already emitting OpenLineage events, I would keep Marquez on the shortlist. For analysts asking what a metric means or which dataset is approved, I would begin with the broader catalog options.

My preference is to buy for a defined requirement. If lineage investigation is the actual funded project, a governance roadmap should not automatically turn it into a much larger platform implementation.

How I Reviewed Marquez

I evaluated Marquez’s published technical behavior, architecture, and Apache 2.0 license against the needs of a self-hosted data platform team. The assessment follows the documented seeded workflow through real event ingestion, then considers lineage coverage and production responsibilities.

This is a documented-workflow evaluation; I did not benchmark a running deployment. My recommendations distinguish supported capabilities from outcomes that depend on instrumentation or deployment choices. Rival comparisons focus on documented metadata models and operating options rather than presumed superiority.

Pricing and licensing checked October 2026.

Should You Choose Marquez?

Choose Marquez for an engineer-owned lineage service, especially if OpenLineage is already part of the stack. I think its clearest value is putting run context and dataset dependencies behind an accessible interface and API without introducing a software subscription.

I would choose a different starting point if the main requirement is business glossary stewardship, broader catalog governance, or data-quality test management. DataHub and OpenMetadata fit those conversations better. A managed-service requirement should also influence the shortlist from the beginning.

My recommended next step is a contained self-hosted pilot around one meaningful reporting pipeline, with an explicit operational owner. Aim for dependable metadata that helps someone understand a real dependency before expanding coverage to more pipelines.

If that focused service is what your team needs, Marquez earns serious consideration.

Marquez FAQ

Is Marquez free?

The open-source software has a $0 Apache 2.0 license. Hosting and engineering administration remain separate costs. My budget would include those operating costs even though the software requires no subscription.

What is the difference between Marquez and OpenLineage?

OpenLineage defines the event standard and provides collection integrations. Marquez is a backend that receives, stores, and visualizes that metadata. Choosing Marquez does not automatically instrument every pipeline.

Does Marquez support column-level lineage?

Yes. Marquez has a column-lineage web view and API. The level of detail depends on incoming field mappings, and the API restricts historical downstream queries using versioned nodes.

Is Marquez a data catalog?

Marquez provides catalog functionality, including search and dataset or field tags, alongside operational metadata management. I would not equate that with a complete governance program. Business glossary stewardship is a stronger reason to compare DataHub or OpenMetadata.

Is Marquez secure by default?

The default HTTP API requires neither authentication nor authorization. A production deployment needs suitable network restrictions and access enforcement. Client-side bearer-token configuration alone does not secure the backend.