OpenLineage Compatibility Update: Q4 2026
Executive summary
This is our fourth update on which vendors produce and consume OpenLineage, and the first since Q1 2026. Two things are different this time. The landscape has moved: two more vendors now play both roles, six new names enter the table, and several entries have weakened. And the table is no longer maintained by hand. It is generated from a tracking sheet that we build with help from the BearingNode Knowledge Graph, and checked against primary sources, with every change traced to evidence.
Key points:
Dual-role is spreading. IBM and Feast now both produce and consume OpenLineage, joining Snowflake, Databricks and others. Nine vendors in the table do.
Vendor claims are catching up with public evidence. Snowflake's consumer role is now publicly documented, Solidatus is on the official ecosystem page, and Alation documents an OpenLineage integration.
Six new entries: Foundational, Precisely, Provero, Acceldata, Apache Hive and Orchestra.
One vendor is now marked Unsupported. Bigeye has told us directly that it has no plans to support OpenLineage.
Some entries have weakened. Metaphor's platform was acquired by KPMG, the Amundsen repository has been archived, and the Dagster integration has left the OpenLineage repository.
AI agents are the open question. Agents now reach governed data directly, on behalf of people or autonomously. The standard assumes work that was declared in advance, and the community is debating how observability and governance should handle work that was not.
Still no Financial Services working group.
As before, this is a directional summary, not an authoritative compatibility index. Treat it as a starting point for your own investigation.
What changed since Q1 2026
Vendors that now play both roles
IBM is now listed in both roles on the official ecosystem page. watsonx.data emits OpenLineage events; watsonx.data intelligence consumes them, and since May 2026 can export lineage in OpenLineage format. We previously tracked IBM as a consumer through Manta. The entry is now IBM (watsonx).
Feast, the open-source feature store, is now listed as both producer and consumer, and documents its OpenLineage support.
Claims that now have public evidence
In Q1 several entries rested on what vendors had told us directly. Three of them can now be checked by anyone.
Snowflake. We recorded Snowflake as producer and consumer in Q1. On 3 September 2026 its external lineage feature became generally available: dbt, Airflow and other tools can send OpenLineage events to a Snowflake REST endpoint, and the lineage appears alongside Snowflake's own. The official ecosystem page still lists it as a producer only.
Solidatus is now listed on the ecosystem page as a consumer, with its own product page for the integration.
Alation was Unverifiable in Q1. It now documents an OpenLineage integration for Alation Cloud Service, including a direct API and an Airflow integration in beta. It is still not on the ecosystem page, so we rate it on vendor documentation alone.
One has not caught up. Databricks remains producer and consumer on the strength of direct confirmation, but it is on neither list of the official ecosystem page, and we found no public documentation of Unity Catalog ingesting OpenLineage events.
New entries
Foundational (producer and consumer): exports lineage derived from static code analysis as OpenLineage events, and ingests runtime events. Documentation.
Precisely (consumer): the Data Integrity Suite ingests OpenLineage events from pipelines and query engines. Vendor write-up.
Provero (producer): an open-source data quality engine that emits OpenLineage events with data quality facets. Exporter code.
Acceldata (consumer): not on the ecosystem page, but its documentation now makes OpenLineage the supported path for Airflow observability and deprecates its own SDK and plugin in favour of it.
Apache Hive (producer): not on the ecosystem page, but a Hive integration is maintained in the OpenLineage repository, and Hive on Dataproc is one of the three producers covered by the compatibility tests.
Orchestra (Unverifiable): a declarative orchestration platform for data pipelines, dbt, Python and AI agents. It ships its own built-in lineage. We found no OpenLineage emission or ingestion in its documentation, product pages, blog or integrations list, or in the OpenLineage GitHub organisation, and have not yet confirmed with the vendor.
Acceldata is worth a second look. A vendor retiring its proprietary integration in favour of the open standard is the strongest adoption signal in this update.
Unsupported
Bigeye moves from Unverifiable to Unsupported. The vendor has told us directly that it has no plans to support OpenLineage. Bigeye has its own lineage API; it is simply not built on this standard. We would rather print a clear "no" than leave an open question.
Entries that have weakened
Metaphor: the company's site now redirects to KPMG's announcement that it acquired Metaphor's technology platform. It remains on the ecosystem page.
Amundsen: the project's GitHub repository has been archived. We flagged slowing activity in March; this confirms it.
Dagster: the integration was removed from the OpenLineage repository in October 2025 (PR 3844) and now lives in a separate dagster-openlineage package. It works, but it is no longer maintained alongside the standard.
Grai: little recent activity, and its OpenLineage documentation link is broken.
A role we can no longer evidence
Monte Carlo was listed as a consumer in Q1. We could not find an OpenLineage integration in its documentation, which describes query tagging and a proprietary push API, so we no longer show a role. The status stays Unverifiable, which means we could not find confirmable public evidence; it does not imply the vendor lacks the capability.
The Q4 2026 table
The table covers 48 vendors, grouped by category. We track a number of them in the BearingNode Knowledge Graph, which Jana, BearingNode's AI consultant, interacts with to help build this tracking sheet. The graph is in development, and we will provide more notes on it in future editions.
Status uses the same scale as Q1 (Mature, Developing, Basic, Unverifiable) with one addition: Unsupported, for a vendor that has confirmed it has no plans to support OpenLineage. Statuses are carried forward from Q1 unless the notes say otherwise. They are our judgement, not a test result.
"On ecosystem page" refers to the source files of the official OpenLineage ecosystem page, pinned to the last commit that changed them (10 August 2026).
Cloud / Hyperscaler
Vendor | Producer | Consumer | Status | On ecosystem page |
|---|---|---|---|---|
AWS (SageMaker Unified Studio & Catalog) † | Yes | Yes | Developing | Partial |
Google Cloud (Dataplex) | Yes | Yes | Mature | Yes |
Microsoft (Purview) | – | Yes | Developing | Yes |
Orchestration / ETL
Vendor | Producer | Consumer | Status | On ecosystem page |
|---|---|---|---|---|
Anyscale | Yes | – | Basic | Yes |
Apache Airflow | Yes | – | Mature | Yes |
Astronomer | – | Yes | Mature | Yes |
Dagster † | Yes | – | Developing | Yes |
DAGWorks (Hamilton) | Yes | – | Basic | Yes |
dbt | Yes | – | Mature | Yes |
Debezium | Yes | – | Developing | Yes |
Feast | Yes | Yes | Basic | Yes |
Great Expectations | Yes | – | Basic | Yes |
Keboola | Yes | – | Developing | Yes |
Matillion | Yes | – | Developing | Yes |
Orchestra † | – | – | Unverifiable | No |
SnapLogic | Yes | – | Developing | Yes |
Compute / Processing Engines
Vendor | Producer | Consumer | Status | On ecosystem page |
|---|---|---|---|---|
Apache Flink | Yes | – | Mature | Yes |
Apache Hive | Yes | – | Basic | No |
Apache Spark | Yes | – | Mature | Yes |
Trino | Yes | – | Mature | Yes |
Data Platform
Vendor | Producer | Consumer | Status | On ecosystem page |
|---|---|---|---|---|
Databricks † | Yes | Yes | Mature | No |
Snowflake | Yes | Yes | Mature | Partial |
Data Catalog / Governance
Vendor | Producer | Consumer | Status | On ecosystem page |
|---|---|---|---|---|
Alation | – | Yes | Basic | No |
Amundsen † | – | Yes | Basic | Yes |
Ataccama | – | Yes | Developing | Yes |
Atlan | – | Yes | Developing | Yes |
Collate | – | Yes | Basic | Yes |
Collibra | – | Yes | Basic | Yes |
Data.Rentgen (MWS) | – | Yes | Basic | Yes |
DataHub | – | Yes | Mature | Yes |
Egeria | Yes | Yes | Mature | Yes |
Foundational | Yes | Yes | Basic | Yes |
Grai † | – | Yes | Basic | Yes |
IBM (watsonx) | Yes | Yes | Developing | Yes |
ILUM | – | Yes | Basic | Yes |
Marquez † | – | Yes | Mature | Yes |
Metaphor † | – | Yes | Developing | Yes |
OpenMetadata | – | Yes | Mature | Yes |
Pentaho | – | Yes | Developing | Yes |
Precisely (Data Integrity Suite) | – | Yes | Basic | Yes |
Select Star | – | Yes | Developing | Yes |
Data Quality & Observability
Vendor | Producer | Consumer | Status | On ecosystem page |
|---|---|---|---|---|
Acceldata | – | Yes | Developing | No |
Bigeye † | – | – | Unsupported | No |
Datadog | – | Yes | Mature | Yes |
Monte Carlo † | – | – | Unverifiable | No |
Oleander | Yes | Yes | Developing | Yes |
Provero | Yes | – | Basic | Yes |
Solidatus | – | Yes | Developing | Yes |
Notes (†)
AWS (SageMaker Unified Studio & Catalog): Listed as a consumer only. The producer role rests on vendor conversations.
Dagster: Integration moved: the Dagster integration was removed from the OpenLineage repo (PR 3844, closed 3 Oct 2025). It is now the dagster-openlineage package on PyPI (0.2.1, May 2026). The Q1 comment "native integration in core platform" is no longer accurate.
Orchestra: No OpenLineage emission or ingestion found in the vendor's documentation, product pages, blog or integrations list, or in the OpenLineage GitHub organisation (checked 23 Oct 2026). It has its own built-in lineage. Not confirmed with the vendor.
Databricks: Not on the official ecosystem page. Consumer role confirmed directly with the vendor (March 2026), not publicly documented.
Marquez: Release cadence: the latest tagged release is 0.50.0 (24 Oct 2024), although the repository is still receiving commits (releases).
Amundsen: Archived: the amundsen-io/amundsen GitHub repository is archived (last push 10 Sep 2026). Still on the ecosystem page.
Grai: Low activity: grai-core last pushed 30 Jan 2026 and the OpenLineage docs link is broken.
Metaphor: Acquired: metaphor.io now redirects to KPMG's April 2025 announcement of acquiring Metaphor's technology platform. Still on the ecosystem page. Standalone product status unconfirmed.
Monte Carlo: No role shown. Our Q1 table listed a consumer role, but no OpenLineage integration could be evidenced in the vendor's documentation, which describes query tagging and a proprietary push API.
Bigeye: Unsupported: the vendor has told BearingNode directly that it has no plans to support OpenLineage. This is direct confirmation and is not publicly documented. The vendor's own lineage API is not built on OpenLineage.
Agents are the next producers, and the standard assumes declared jobs
Everything in the table above describes systems that were set up in advance: a pipeline, an orchestrator, a catalogue connected to a lineage backend. A growing share of data access is not like that. AI agents now reach governed data directly, sometimes on behalf of a person and sometimes autonomously. How that access is observed and governed is becoming a pointed question in the open-standards community.
Observability and governance are different questions. Governance says what should happen: who may act, under what authority, within which policy. Observability shows what is happening: which dataset was reached, by which call, and what followed. By observability here we mean data observability, of which lineage is a part, as distinct from software and infrastructure observability. Management is the operational handling of known data assets. We have argued before that these are three different things, and that AI observability is not AI governance. Agents make the confusion expensive.
Where the standard's model strains. In OpenLineage, ownership hangs off a job, and a job is declared before anything runs. An agent's ad hoc access has no declared job, and the caller changes from one run to the next. A scheduled agent is different: it is a declared job, and the existing producer model serves it. The gap is ad hoc access where nothing was declared in advance.
What the community is doing. The question is open in the OpenLineage project. Issue 4484, raised by BearingNode in April and still open, asks how lineage should represent runtime, actor-initiated data interactions such as MCP calls. Issue 4409 raises agent-level attribution. PR 4480 proposed an agent identifier and a signed attestation of the policy the agent acted under; it was closed, and the maintainers were unsure it belonged in the core specification.
That last discussion shows the split. Capturing the call to a governed dataset, so that an analyst can reconstruct the run, is a lineage question. Recording the authority an agent acted under, and attesting to the policy, is a governance question. Our position is to keep lineage to capture and to leave authority and attestation to governance tooling.
What we have built. BearingNode Lab is our public research repository. Its first workstream, mcp-lineage, is a reference implementation: an MCP server that sends an OpenLineage event to Marquez for each SQL statement an agent runs, against synthetic data. It is a reference demo, not a production system, and it covers structured data reached through SQL only. Its evidence matrix scores it against eleven requirements: two met, nine partly met, none unmet, with the failures in the table and each row reproducible from a command. The authority an agent acted under is a stated gap. We found no attribute that records it in OpenLineage, MCP or OpenTelemetry.
None of the 48 vendors in the table was assessed for agent-level capture this quarter. We expect it to become a dimension in future editions.
Being a consumer is not one thing
"Consumes OpenLineage" covers at least two different architectures.
Marquez stores OpenLineage events in a model built for them. DataHub, by its own description on the ecosystem page, uses a converter that translates OpenLineage events into DataHub's own metadata model. Both are genuine consumers. But translation means reshaping, and reshaping means something can be lost at the boundary.
A DataHub release earlier this year shows where the strain appears. It added a fix that sanitises OpenLineage dataset names containing the literal text "None", produced by Airflow operators that build names carelessly, so that lineage edges stitch to the same identity as DataHub's native sources. Identity resolution across naming conventions is the fragile joint in this ecosystem.
The compatibility-tests framework tests producers in some depth. It tests one consumer. What survives the journey into each consumer (which facets, which identities, how much column-level detail) is untested territory. It matters more once those events are used as evidence of who reached which data, and it is a dimension we expect to add to this table once there is evidence for more than a handful of vendors.
Why nobody has built the open collection layer
Data observability sells to governance buyers, sales-led and priced per seat or per asset. Those economics do not fund a neutral, open-source collector of the kind OpenTelemetry has for software. Catalogues and cloud platforms consume OpenLineage and stop there, and several quality and observability vendors gather lineage through their own proprietary collection instead. Where open-standards engagement did appear, it was often absorbed: Databand and MANTA into IBM, Metaplane into Datadog, and now Metaphor's platform into KPMG. The de facto free tier of this ecosystem is still the open-source layer itself: Marquez, DataHub Core, OpenMetadata.
What is still missing
In Q1 we named three gaps. We found nothing this quarter to suggest any has closed, and we add a fourth.
1. A Financial Services working group. There is still no sector working group in the OpenLineage community. Regulated buyers continue to need guidance on evidencing controls, audit trails and lineage completeness.
2. Consumption events. Who uses data, and for what business purpose, remains largely untracked in the standard. Where a runtime actor such as an agent initiates the access, this is the gap our Lab workstream works on (see above).
3. A stronger testing framework. The compatibility-tests repository is active: 196 open issues and 11 open pull requests as of 23 October, up from 141 open issues in March. Its coverage today is Spark and Hive on Dataproc and dbt on the producer side, and Dataplex on the consumer side. That is real, CI-backed evidence, and it is narrow. Most of the vendors in our table are not tested there at all.
4. A way to record agent-initiated access. Ad hoc access by an agent has no declared job to hang lineage on, and the authority an agent acted under is recorded nowhere in the standards we looked at. The discussion is under way, and it is unresolved.
How this edition was built
Previous editions were maintained by hand. This one was built in three steps:
Start from our tracking data. We build the tracking sheet with help from the BearingNode Knowledge Graph, which Jana interacts with, alongside our Q1 table.
Fact-check everything. Every vendor was checked against the source files of the official ecosystem page. Where a vendor was unlisted, or the sources disagreed, we read the vendor's own documentation.
Record the differences. Where the evidence contradicted our Q1 table, we changed the table and recorded why.
The exercise found errors in our own Q1 table. It was out of date on IBM, Feast and Alation, and overstated two projects that have since lost momentum. We think that is the honest state of vendor compatibility tracking anywhere: every source drifts, and the only remedy is to check on a schedule and publish what changed.
The method is not specific to OpenLineage. We intend to apply the same process to other open standards, starting with OpenTelemetry, in future editions. Like BearingNode Lab, this edition was built with AI assistance throughout. We ask you to verify what you read here rather than trust it; see the Lab's disclosure.
What we expect next (2027)
More dual-role platforms. Once a data platform accepts external lineage, as Snowflake now does, others will follow.
Agent access becomes a question buyers ask. "Which agents reached which data, and on whose authority?" will sit alongside "do you consume OpenLineage?"
Consumer conformance becomes a question buyers ask. "Do you consume OpenLineage?" will give way to "what do you keep?"
Further consolidation among smaller catalogue and observability vendors.
Testing remains the bottleneck. Listings will keep outrunning evidence until more vendors contribute to the compatibility tests.
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 and consumer coverage, gap analysis against the ecosystem, and a prioritised action plan. Reach out at bearingnode.com.
Notes and Disclaimer
This article is based on BearingNode's internal tracking, the BearingNode Knowledge Graph, public vendor documentation and official OpenLineage ecosystem listings, checked on 8 and 9 October 2026. The source files of the ecosystem page had not changed by 23 October 2026, when we also re-checked the compatibility-tests figures and the status of the Amundsen repository. It is a directional assessment, not an audited or independently verified compatibility index.
Evidence basis. Every vendor was checked against the OpenLineage Ecosystem Page, whose listings are self-submitted by vendors and lag real-world adoption. Vendor documentation was read for vendors whose status had changed or was disputed, and not for the rest. Nothing in this table has been tested by us against the OpenLineage specification.
Status ratings are BearingNode's judgement. "Unverifiable" means we could not find confirmable public evidence; it does not imply the vendor lacks the capability. "Unsupported" means the vendor has told us directly that it has no plans to support OpenLineage. Some entries rest on direct vendor confirmation that is not publicly documented; these are noted.
About the author: This update was prepared by the BearingNode Lab team. BearingNode is a consultancy working with organisations on the observability, governance and management of their AI, software and data.
