Bad data quietly kills AI projects. Not with a bang, usually with a slow drift nobody catches until a dashboard reads wrong in a board meeting or a model starts making decisions on numbers that stopped being true three weeks ago. The pattern we see at Shipshape Data is almost always the same: the data broke, and nobody found out until the damage was done.
That is the gap data observability tools fill. They watch your data quality, pipeline health and schema changes, and they tell you when something moves before it turns into an outage or a bad decision. The open source side of this space has grown up a lot. You now have real choices, from a small package you bolt onto an existing dbt project to a full platform that stands comparison with the paid vendors.
This is a run through twelve open source data observability tools worth knowing in 2026. They do not all solve the same problem, which is the first thing to get straight before you shortlist anything. Some test data quality, some track lineage, some catalogue your assets, and a few just watch the infrastructure underneath. For each one you get what it actually does, who it suits, what you get in the box, and where it will bite you. Read the two or three that match your stack and skip the rest.
1. OpenMetadata
OpenMetadata is about as complete as open source gets in this category. It folds metadata management, quality monitoring and lineage into one platform, so if you want a single place that answers "what data do we have and is it healthy", this is a strong first look.
How it works
At the centre sits a metadata store behind a REST API. Connectors pull metadata from your databases, warehouses, pipelines, dashboards and message queues into that store, and OpenMetadata builds a catalogue that tracks schema history, ownership, lineage and quality in one view. You run it on Docker or Kubernetes, and it is built to scale sideways as your estate grows.
What you get in the box
- A searchable web catalogue with automated data profiling
- Over 80 native connectors covering Snowflake, BigQuery, Airflow, Looker and more
- A built-in quality framework for defining and running tests from the UI
- Lineage visualisation and role-based access control
2. DataHub
DataHub started life at LinkedIn and is now looked after by Acryl Data and a wide contributor base. It stores metadata as a graph, which makes it good at the thing relational stores struggle with: tracking relationships between assets across sprawling, distributed environments.
How it works
Everything lives in a generalised metadata graph. Ingestion sources push into it either by pull-based crawling or by streaming over Kafka, so you get a picture that updates as things change rather than on a nightly scan. Lineage queries that would grind a relational store to a halt run cleanly here, even across hundreds of connected datasets.
What you get in the box
- A searchable catalogue with automated lineage tracking
- Ownership and tagging management plus a business glossary
- Connectors for BigQuery, Redshift, dbt and other common tools
- Real-time metadata propagation for teams already running Kafka
The Kafka dependency is the catch. It adds infrastructure weight that smaller teams rarely want, and the built-in quality testing is limited, so you will most likely bolt on Great Expectations or Elementary to cover that side properly. DataHub suits teams already on Kafka who deal with complicated lineage across microservices and mixed platforms. Free under Apache 2.0, with a managed Acryl cloud version at commercial tiers.
3. OpenLineage and Marquez
These two work as a pair, and the pairing is the point. OpenLineage is an open standard that defines how pipelines emit lineage events. Marquez is the reference backend that collects and shows them. Together they give you a vendor-neutral way of tracking data movement across your pipelines without marrying a single platform.
How it works
OpenLineage sets a common event spec that a pipeline tool emits when a job runs, capturing inputs, outputs and run metadata in a standard shape. Marquez receives those events over HTTP and builds a queryable graph of your flows. Spark, dbt and Airflow already ship OpenLineage integrations, so instrumentation is often close to nothing.
Because OpenLineage is a standard and not a product, the lineage you capture today stays portable no matter what backend you move to tomorrow.
Marquez keeps itself deliberately lean. There is no built-in quality testing and the UI is basic next to the fuller platforms, so you will supplement it with a dedicated quality framework. Among the lineage-focused options, this is one of the more composable and lightweight, and it fits teams already on Airflow, Spark or dbt who want lineage without adopting a whole platform. Both are free under Apache 2.0.
4. Elementary
Elementary is the dbt-native option, and it does something the others do not: it lives inside your existing dbt project rather than asking you to stand up another service. If your team already runs dbt, this is the lowest-friction way to get observability.
How it works
It installs as a dbt package and runs as part of your normal dbt workflow. Run results, test outcomes and schema changes get written to tables inside your own warehouse, then surfaced through a local report you view in a browser or push to a storage bucket to share. Because that data sits in your warehouse, you keep control of retention, access and query cost without minding any external infrastructure.
What you get in the box
- Automated anomaly detection on row counts, null rates and freshness
- All your existing dbt test results captured in one structured report
- Trend lines so you catch quality sliding over time, not just one-off failures
- No standalone service to deploy or maintain
The limit is the flip side of the strength. Elementary does not touch non-dbt pipelines, so if you also run Spark jobs or custom ingestion you will need something else for those, and lineage is bounded by the dbt graph rather than your whole estate. Free under Apache 2.0, with a paid cloud tier for managed hosting and richer alerting.
5. ODD Platform
ODD Platform, short for Open Data Discovery, is a catalogue and observability platform built around the OpenDataDiscovery specification. It gives you a structured way to collect, standardise and surface metadata from a spread of sources without hand-writing ingestion for each one.
How it works
It uses the OpenDataDiscovery specification to define how sources emit metadata. Collectors pull from your databases, pipelines and transformation tools into a central backend, which builds a searchable catalogue and lineage graph. Because the spec is standardised, metadata from different sources arrives in a consistent shape, which cuts the normalisation work your team would otherwise do by hand. The whole thing is container-based for Kubernetes or Docker.
Out of the box you get catalogue plus lineage, ownership management and a business glossary, with collectors for Snowflake, PostgreSQL, Airflow and dbt. Built-in quality testing is thin, so pair it with Great Expectations or Soda Core, and the collector ecosystem is smaller than OpenMetadata's or DataHub's, which can mean building your own for niche sources. It suits mid-sized teams that want catalogue and lineage without adopting something heavier. Free under Apache 2.0.
6. Soda Core
Soda Core is a quality framework with a YAML-first approach. Instead of writing tests in Python or SQL, you write readable check files that run against your data directly, which puts quality within reach of analysts as well as engineers.
How it works
It connects straight to your warehouse or database and runs checks written in SodaCL, its YAML check language. You run them from the command line or drop them inside an orchestrator like Airflow, and results come back as pass, fail or warning. That makes it simple to fold into an automated testing pipeline without much setup.
What you get in the box
- Freshness and row count monitoring
- Missing values and duplicate detection
- Schema change detection
- Custom SQL-based checks, with support for Snowflake, BigQuery, Redshift and PostgreSQL
SodaCL is readable enough that a non-engineer can review and add checks without following the execution logic underneath. The gap is that Soda Core does no lineage tracking and no cataloguing at all, so if asset discovery matters you will pair it with a separate metadata platform. It fits teams that want lightweight, code-defined checks in their CI/CD without a full platform. Free under Apache 2.0, with a commercial managed cloud on top.
7. Great Expectations
Great Expectations is one of the most widely adopted quality frameworks going. You write declarative rules called "expectations" that describe what your data should look like, then run them against the real thing to catch failures early.
How it works
It connects to sources through datasource objects and runs validation suites you define in Python or JSON. Each run produces a detailed results document you can store, share or feed into alerting. It works on batches, so you point it at a dataset and run your suite on demand or as a scheduled pipeline step. The auto-generated data docs, HTML reports of validation results and dataset statistics, are the standout feature: they make it easy to hand quality reports to stakeholders who never touch code.
What you get in the box
- A deep library of built-in expectations: nullness, uniqueness, value ranges, regex, referential integrity
- Auto-generated, human-readable data docs
- Version-controllable rules you can review in pull requests
- Natural fit inside Airflow or Prefect as a validation step
There is no native lineage or cataloguing, and the initial setup takes real configuration effort. Teams without Python will find the curve steeper than a YAML tool like Soda Core. Best for Python-centric teams that want precise, code-defined rules. Free under Apache 2.0, managed cloud at commercial tiers.
8. Deequ
Deequ is a quality library from Amazon, built on Apache Spark. Most tools here run queries against your warehouse. Deequ does its checks inside the Spark computation layer instead, which is what makes it suited to large batch workloads where firing off separate validation queries would cost a fortune.
How it works
It computes quality metrics as part of your existing Spark job rather than as a separate downstream check. You define constraints and metrics in Scala or Python, and Deequ evaluates them against the distributed dataset using Spark. It stashes computed metrics in a repository, so you can watch how measurements shift across runs. The automatic constraint suggestion is genuinely handy: point it at an unfamiliar dataset with no quality documentation and it profiles the data and proposes a baseline for you.
The costs are plain. There is no web UI, no lineage and no cataloguing, and you need solid Spark knowledge to run it well, which shuts out teams without that background. It suits Spark-native teams processing large volumes in batch who want validation baked into the pipeline. Free under Apache 2.0.
9. DQOps
DQOps, for Data Quality Operations, pairs a YAML check system with a built-in web UI and a sensor-based design. It aims at teams that want scheduled quality monitoring without writing custom pipeline code for every check.
How it works
It connects over JDBC and runs checks on a schedule. You define them in YAML inside a DQOps workspace, and the platform turns those into SQL that runs against your warehouse. Results land in a local time-series store that the UI reads to show trends and anomaly flags over time. That combination lets a team iterate on rules visually while keeping the configuration in version control.
What you get in the box
- A browser UI for managing checks, viewing results and setting alert rules
- Checks for completeness, validity, consistency and timeliness
- Support for Snowflake, BigQuery, Redshift and PostgreSQL
- Built-in anomaly detection against historical baselines
No native lineage or cataloguing, so bring a separate tool if discovery matters, and the connector library is narrower than the older frameworks, which can leave gaps for less common sources. Best for teams wanting scheduled, visual quality monitoring without a full metadata platform. Free under Apache 2.0, commercial cloud on top.
10. OpenTelemetry
OpenTelemetry belongs to a different family from most of this list. It does not test data quality or catalogue assets. It gives you a vendor-neutral way to collect telemetry, the traces, metrics and logs, from your applications and pipelines through one standard instrumentation layer.
How it works
It is a Cloud Native Computing Foundation project offering a consistent set of APIs, SDKs and collector agents for instrumenting any application. You add the SDKs to your pipeline code, and the collector gathers traces, metrics and logs before forwarding them to whatever backend you choose, Prometheus, Grafana or a commercial platform. Because the export format is vendor-neutral, you can switch backend later without re-instrumenting your code.
What you get in the box
- Language SDKs for Python, Java, Go and several others
- A standalone collector for ingestion, transformation and export
- Distributed traces that follow a single event through every pipeline stage
- Pinpointing of exactly where latency or failure happened
It does no quality testing, lineage or cataloguing. It watches how your systems run, not whether your data is any good, so you close that gap by pairing it with a quality framework like Soda Core. Best for teams running custom pipeline code or microservices who want deep operational visibility. Free under Apache 2.0.
11. Prometheus
Prometheus is a time-series monitoring system, born at SoundCloud and now a graduated CNCF project. It is not a data quality tool in the usual sense, but it sits next to OpenTelemetry and Grafana as a core part of the infrastructure monitoring layer a lot of data teams rely on to keep an eye on pipeline health.
How it works
It works on a pull model, periodically scraping HTTP endpoints that expose metrics in a standard text format. Those metrics land in a local time-series database you query with PromQL, its own query language, to analyse trends and drive alerting. It handles high-cardinality data well, which makes it reliable for pipelines that emit a large number of distinct metric labels.
What you get in the box
- A built-in alerting engine, Alertmanager
- A simple web UI for ad hoc PromQL queries
- Exporters for PostgreSQL, Kafka and Airflow, so most teams instrument without custom endpoints
- Reliable operational metrics for latency, job failure rates and queue depth
No quality testing, lineage or cataloguing here either, and long-term retention needs a remote store like Thanos or Cortex, which adds complexity. Best when you need dependable operational metrics alongside a battle-tested alerting layer. Free under Apache 2.0.
12. Grafana
Grafana is the visualisation layer most teams pair with Prometheus, OpenTelemetry or another metric backend. On its own it neither collects nor stores data. What it does is turn raw telemetry into dashboards that make pipeline health legible to engineers and stakeholders without either group writing queries by hand.
How it works
It connects to your existing sources through a plugin system and queries them directly. You point data source connections at Prometheus, ClickHouse, PostgreSQL or whatever you run, and Grafana pulls real-time and historical data on demand as dashboards load. The rendering engine handles time-series graphs, heatmaps, stat panels and alert views from one interface.
What you get in the box
- A drag-and-drop dashboard builder
- A large library of community dashboard templates, including Airflow and Kafka
- Built-in alerting to Slack, PagerDuty or email
- Over 150 data source plugins
The pre-built templates get most teams to meaningful pipeline visibility within hours rather than days. As with the others in this group, there is no quality testing, lineage or cataloguing, and Grafana only shows what you instrument, so sparse metric coverage means sparse dashboards no matter how well they are laid out. Note the licence difference: the open source edition is AGPLv3, not Apache 2.0, so check that against your own distribution rules before you commit. Free to self-host, commercial cloud on top.
How to actually choose
Twelve tools, and no single winner, because they answer different questions. Roughly, they fall into three camps. Quality testing: Soda Core, Great Expectations, Deequ, DQOps and Elementary. Cataloguing and lineage: OpenMetadata, DataHub, ODD Platform, OpenLineage with Marquez. Infrastructure monitoring: OpenTelemetry, Prometheus and Grafana. Most mature stacks end up running two or three of these rather than pretending one covers everything.
Start with your biggest gap, not the longest feature list. If you run dbt, Elementary is the fastest route to quality monitoring with almost no setup. If you need governance and discovery at scale, look at OpenMetadata or DataHub first. If your world is heavy Spark batch, Deequ before anything else. If you want portable lineage with no lock-in, OpenLineage with Marquez. And if the real problem is that nobody can see the pipeline running at all, the OpenTelemetry, Prometheus and Grafana trio is the operational baseline.
One warning worth repeating. Picking a tool before you understand your own data architecture is how teams end up with coverage gaps that only surface during an audit or an outage, which are the two worst moments to find them. We have walked into this more than once: a shiny observability platform installed, and the one pipeline that keeps breaking sitting outside everything it watches. Map your estate first, then buy for the gaps.
If you are trying to move AI work from pilot into production and you are not sure which of these fits your stack, that is the kind of thing we help teams untangle at Shipshape Data. Talk to us and start with a clear read on where your data actually stands.