OpenLineage Compatibility Update: Q1 2026

Executive summary

Since our last "Vendor Integration Status" snapshot (March 2025, updated August 2025), the OpenLineage ecosystem has continued to mature from a set of mostly producer-led integrations into a more clearly segmented marketplace, where vendors differentiate by how they participate in lineage: as producers, consumers, or dual-role players.

Key Points:

• Refreshed view of compatibility status and expansion of categories

• Capability to the standard has progressed significantly since our last update

• Vendor neutrality and collaboration is coming to the fore as "data gravity", increasingly a concern for buyers

• Capability testing framework is maturing with new collaborators / committers

• Regulated industries (especially Financial Services) with higher audit / 3 lines of defence risk management models continue to focus most on data lineage

This article provides a directional summary of observed changes and notable gaps — it is not an authoritative or exhaustive compatibility reference. It summarises what has changed, what's still missing, and how to approach vendor evaluation pragmatically in 2026. Treat it as a starting framework for your own investigation, not a substitute for it.

What's changed since 2025

1) The ecosystem has matured (materially)

Our latest internal update reflects almost twelve months of engagement since the initial March 2025 analysis, including 30+ vendor conversations — suggesting continued progress in capability and deployment coverage, though the picture remains uneven across categories. What was once "can it emit an event?" is now shifting toward "how complete, testable, and operational is the integration?" — though for many vendors, a definitive answer to that question is not yet available from public sources.

2) Producers vs consumers is now useful for architectural decisioning

A clearer pattern has emerged:

1. Producers generate lineage events from real processing activity (e.g., Databricks, Snowflake, Airflow, dbt).

2. Consumers ingest and enrich lineage for governance/observability (e.g., DataHub, Atlan, Microsoft Purview).

3. Dual-role players both produce and consume, enabling richer observability ecosystems (e.g., Google Dataplex).

Note on AWS: Amazon SageMaker Unified Studio & Catalog (formerly Amazon DataZone — rebranded in 2025, with the console URL at console.aws.amazon.com/datazone confirming continuity) appears as Consumer-only on the official OpenLineage ecosystem page as of March 2026. Its producer role — via processing jobs running within SageMaker Unified Studio, which consolidates AWS Glue, Amazon EMR, Athena, and Redshift — has been confirmed through independent market research and vendor conversations (2025–2026) but is not yet listed on the official ecosystem page. It should not be cited as a confirmed dual-role platform without direct vendor validation.

Why this matters in 2026: organisations need both sides working together. Producer-only coverage without a consumer layer fails to deliver governance outcomes; consumer-only without reliable producers becomes "lineage theatre".

3) Compatibility testing is becoming a differentiator

The compatibility testing framework appears to be maturing, with more collaborators and committers contributing to the OpenLineage compatibility-tests repository and better approaches emerging to gradation beyond a binary "supports/doesn't support". This is a directional shift worth noting: buyers should start to ask for evidence of behaviour (edge cases, completeness, versioning) rather than accepting marketing claims. Alternatively, buyers are able to come to BearingNode to help them select their vendor. The direction is right; the maturity is developing.

The 2026 landscape: how to think about vendors

A practical classification model (for buyers)

Category A — Lineage Producers (execution-layer emitters)

These tools sit where work actually happens (pipelines, transformations, orchestration) and emit OpenLineage events. Typical examples include Databricks, Snowflake, Airflow, dbt.

What to ask in 2026:

• Do events cover all critical job types or only a subset?

• Are events emitted consistently across environments (dev/test/prod)?

• How are failures, retries, and partial runs represented?

Category B — Lineage Consumers (governance/observability ingest & enrich)

These tools ingest events and add context: metadata, ownership, classification, policy mapping, and user-facing discovery. Examples include DataHub, Atlan, Microsoft Purview.

Notably, the consumer layer has broadened significantly since our last update. In addition to established names, the official ecosystem now includes Marquez, OpenMetadata, Egeria, Ataccama, Select Star, Grai, Collate, Metaphor, Pentaho, Amundsen, and ILUM — giving buyers considerably more choice, but also more integration complexity to evaluate. Collibra, one of the larger enterprise names in this space, currently holds only a Basic status on the official compatibility matrix, which is worth factoring into procurement decisions.

For financial services organisations specifically, Solidatus is worth examining: it has confirmed basic Consumer support (direct confirmation, March 2026) and is primarily focused on regulatory and financial data lineage use cases, though it is not yet listed on the official OpenLineage ecosystem page.

What to ask in 2026:

• What enrichment is native vs requires custom work?

• How is lineage reconciled across multiple producers?

• Can you evidence audit-ready lineage views for regulated use cases?

Category C — Dual-role ecosystems (platform plays)

These vendors aim to provide an end-to-end experience by both producing and consuming lineage. The clearest confirmed examples are Google Dataplex and Egeria. Apache Airflow (as a project) is listed as a Producer on the official ecosystem page; Astronomer — its enterprise managed platform — is listed separately as a Consumer. Together they effectively cover both sides, though they should not be conflated as a single dual-role vendor.

Note on AWS: As above — AWS SageMaker Unified Studio & Catalog should not be assumed dual-role without direct vendor validation. Its producer capability is confirmed through independent research but is not yet reflected in the official ecosystem listing.

What to ask in 2026:

• Is OpenLineage first-class, or a "bridge" to a proprietary model?

• How portable is lineage if you change platforms?

• What is the vendor's stance on neutrality and collaboration?

What's still missing (and why it matters)

Our August 2025 update identified three emerging needs. Revisiting these in March 2026, none have been substantively addressed by the community or vendors — they remain open priorities:

1) A Financial Services Working Group

The community needs sector-specific guidance for regulatory compliance. In practice, FS buyers need clarity on:

• Evidencing controls

• Audit trails

• Lineage completeness thresholds

• How lineage supports three-lines-of-defence models

No formal Financial Services working group exists within the OpenLineage community as of March 2026. This represents a meaningful gap — and an opportunity for early movers to shape the standard.

2) "Consumption events" (the business context gap)

A major blind spot remains. Who uses data and for what business purpose is largely untracked. Without this, lineage answers "how did it move?" but not "why does it matter?" — limiting impact for governance, risk, and value measurement. This remains the most significant unresolved gap in the ecosystem.

This is going to become a real topic as we continue to deploy Agentic and Human consumption of datasets. For instance, MCP enabled agents accessing datasets need to be logged as lineage events, especially if this involves client impactful decisioning.

3) A stronger integration testing framework

The compatibility testing repositor github.com/OpenLineage/compatibility-tests is active — with 141 open issues and regular contributions from Spark Dataproc, dbt, and Dataplex maintainers as of March 2026 — but coverage remains incomplete. In 2026, this should evolve into repeatable buyer-friendly assurance, such as:

• Conformance profiles

• Scenario-based test packs

• Published evidence of coverage

The raw infrastructure exists; the gap is formalising it into something buyers can reference in procurement.

What future is BearingNode investing in bringing about?

BearingNode is not a passive observer of the OpenLineage ecosystem. We have a point of view — and we are backing it.

Coding agents already know open standards. That changes everything.

Coding agents — the AI tools increasingly doing real implementation work in data engineering teams — are trained on publicly available code, documentation, and repositories. That means a mature, well-documented open standard with a healthy public implementation repo is not just useful for human architects. It is something coding agents already understand.

When an agent is asked to instrument a pipeline, suggest an integration pattern, or generate a conformant event schema, it will default to what it knows. If OpenLineage is mature, consistent, and well-evidenced in public repos, agents produce better, more conformant outputs — without bespoke instruction. Proprietary lineage models do not get that benefit. They are invisible to the agents doing the work.

Vendor-neutral architectures become self-reinforcing.

 For buyers, this creates a compounding structural advantage. Build your architecture around an open standard that coding agents already understand, and you gain vendor portability and AI-assisted development aligned to your architecture — essentially for free.

The standard becomes the shared language between vendors, buyers, and the AI agents implementing the work. That alignment compounds over time. Proprietary lock-in, by contrast, becomes a progressively heavier drag as agentic tooling matures.

That is why BearingNode has invested in the OpenLineage compatibility repo?

 Our investment in the OpenLineage compatibility-tests repository is not altruism. It is a direct bet on this thesis.

More test coverage, more committers, more evidence-based conformance: each of these raises the quality floor of what coding agents can do with OpenLineage. Maturing the standard now accelerates the future we believe is coming. We are building the infrastructure layer that makes vendor-neutral, AI-native data architectures possible — and we are doing it in the open.

Financial Services should be first — not last.

 FS organisations operate under conditions that make this argument most urgent: audit requirements, three-lines-of-defence risk models, and regulators who demand evidence, not diagrams.

Coding agents are already being deployed in FS data engineering. If those agents are generating lineage instrumentation, integration code, and pipeline logic, then the standard they work within is not an architectural preference — it is a risk management decision. Aligning to a mature open standard now means your AI-assisted development is producing outputs that are auditable, portable, and aligned to an independently verifiable framework.

We believe Financial Services should be shaping this standard, not waiting for it to arrive. That is why we are pushing for a formal Financial Services working group within the OpenLineage community — and why we are investing in the foundation that makes that group's work meaningful before it exists.

A note on how to use this article

This article provides a directional view of OpenLineage vendor compatibility — it is not a definitive or authoritative compatibility index. It reflects information available through Q1 2026 from public sources, official ecosystem listings, and vendor briefings.

 Several important caveats apply:

-          Official listings lag real-world adoption. The OpenLineage ecosystem page and compatibility-tests repository are the most reliable public references, but both trail actual vendor capability by months or longer.

-          Vendor briefings are not the same as independent verification. Where evidence is sourced from vendor communications rather than the official ecosystem page or open-source contributions, it is noted as such. Readers should validate all claims directly with vendors before procurement or architecture decisions.

-          BearingNode is an active contributor to the OpenLineage compatibility-tests repository. Our assessments are informed by this work, but we retain commercial independence. We do not guarantee accuracy and disclaim liability for decisions based on this content.

-          Unverifiable entries exist. Some vendors that previously appeared in our tracking have been reclassified as "Unverifiable" where prior evidence has been removed or cannot be confirmed against current public sources. This does not imply capability — it means we cannot substantiate a claim.

If you are evaluating vendors for a regulated or enterprise deployment, treat this article as a starting point for discovery, not a shortcut to a conclusion. BearingNode offers structured readiness assessments and vendor evaluation workshops for organisations that need a more rigorous answer.

Implications for regulated industries (2026 view)

Regulated industries continue to focus most on data lineage due to higher audit requirements and three-lines-of-defence risk management models. For these organisations, the "minimum viable lineage" bar is rising:

• Auditability: lineage must be reproducible and explainable, not just visual

• Operational resilience: lineage should support impact analysis and change risk

• Governance integration: lineage must connect to ownership, controls, and policy obligations (not remain a technical diagram)

How to evaluate vendors in 2026 (a pragmatic checklist)

Use this as a lightweight procurement and architecture lens:

• Role fit: Are you buying a producer, consumer, or dual-role platform — and do you have the complementary components?

• Evidence over claims: Ask for test evidence aligned to a compatibility framework (not just "we support OpenLineage").

• Neutrality & portability: Validate how the vendor supports open standards in the face of "data gravity" concerns.

• FS readiness: If you're regulated, ask explicitly how lineage supports audit, controls, and three-lines-of-defence expectations.

• Roadmap alignment: Check whether the vendor is investing in the gaps: consumption events, testing, and sector guidance.

What we expect next (2026–2027)

Based on the direction of travel observed in the ecosystem:

More consumer sophistication: richer enrichment, better reconciliation across producers, and stronger governance workflows. The consumer layer is broadening rapidly — buyers will have more choice but also more integration complexity to manage.

Standardisation of assurance: compatibility testing becomes table stakes for enterprise adoption. The OpenLineage compatibility-tests framework runs continuous checks across a growing range of platforms including Spark, Flink, dbt, and Dataplex (based on public repository activity as of March 2026) — the direction of travel suggests this will expand, and that enterprise buyers will increasingly cite it in RFPs. How quickly that materialises is unclear.

Business-context lineage: pressure will grow to capture "consumption events" to connect lineage to value, risk, and accountability. This remains the most significant unresolved gap in the ecosystem.

FS-led patterns: sector working groups and reference architectures may emerge to accelerate adoption in regulated environments. No formal Financial Services working group exists within the OpenLineage community as of March 2026 — this represents an opportunity for early movers.

Work With Us

If this directional summary is useful, BearingNode can go deeper. We run structured OpenLineage readiness assessments for data and engineering teams — covering your current producer/consumer coverage, gap analysis against the ecosystem, and a prioritised action plan. We also offer a Data Observability & Lineage workshop for senior stakeholders (CDOs, data architects, governance leads) addressing architecture decisions, vendor selection, and regulatory readiness implications.

Vendor compatibility claims in this space require independent validation. We can help you structure that validation for procurement or architecture purposes. Reach out at bearingnode.com.

Closing

The OpenLineage ecosystem is no longer in early experimentation — the direction of travel is toward a competitive, role-differentiated market where buyers can (and should) demand evidence of integration completeness, portability, and audit readiness, particularly in Financial Services.

No definitive compatibility answer exists in the market today. What exists is a clearer set of questions to ask, a maturing testing framework to reference, and a growing set of vendors that understand their position in the lineage value chain. That is progress — but buyers still need to do the work.

Open standards remain the most credible path to scalable data observability, and the transparency we've seen across vendors reinforces that direction.

Notes and Disclaimer

This article is based on BearingNode's internal tracking (updated Q1 2026), public-facing vendor content, official OpenLineage ecosystem listings, and direct vendor conversations conducted between February 2024 and March 2026. It is a directional assessment, not an audited or independently verified compatibility index.

Evidence basis. Assessments draw on four primary source types: the OpenLineage Ecosystem Page (official listings, self-submitted by vendors); the OpenLineage Compatibility Matrix; the OpenLineage Compatibility Tests repository (CI-backed test evidence, incomplete coverage as of March 2026); and direct vendor conversations (supporting context, not primary evidence). Where sources conflict, the more conservative assessment is applied.

Vendor briefings. Some assessments rely on vendor-provided information that has not been independently tested or confirmed against the official ecosystem repository. These are noted in the companion table. Vendor capabilities should be confirmed directly with each vendor before any procurement, architecture, or publication decision.

Unverifiable entries. Several vendors in the companion table are classified as "Unverifiable". This reflects the absence of confirmable public evidence as of March 2026 — it does not imply the vendor lacks the capability.

BearingNode contributor status. BearingNode is an active contributor to the OpenLineage compatibility-tests repository. This informs our assessments but does not constitute endorsement by, or affiliation with, the OpenLineage project or its maintainers.

No liability. BearingNode accepts no liability for decisions made on the basis of this content; it is provided for information and entertainment purposes only