Kindly fill up the following to try out our sandbox experience. We will get back to you at the earliest.
Eleven data observability tools compared, the licenses that changed in the last twelve months, what each one covers, and the arithmetic that decides self host or buy.
Updated on
If you are choosing between running an open source stack and buying a managed platform, the decision turns on three things and none of them is the feature list. It turns on which projects are actually maintained, on how much of what you need sits behind a paid cloud tier in the very projects you were planning to self host, and on what your own engineering time costs. This article answers all three with data fetched on 5 September 2026 from each project own repository and documentation, because in this category the facts move faster than the articles about them.
Three things changed in the twelve months to September 2026 that most published lists have not caught up with: Soda Core moved from an Apache license to a source available one, the Great Expectations repository moved into Fivetran GitHub organization, and Apache Griffin was retired to the Apache Attic. All three are checkable in under a minute and none of the pages ranking for this term has checked them.
Data observability is the practice of continuously monitoring the health of your data across its lifecycle, from source systems through pipelines and transformations to the tables and dashboards people actually use. It tells you which data is wrong, which data stopped arriving, and what breaks downstream when either happens. We explain the discipline itself in more depth in our guide to what data observability is and what it monitors, and if you are still separating the two terms, the boundary between data quality and data observability is where that distinction is drawn properly. This page assumes you have settled both and are now choosing what to run.
Four reasons, stated as what you get rather than as why it matters.
Every business understands the importance of collecting data, but a large data set is not the same as a usable one. Observability is what makes the difference measurable rather than assumed.
Open source data observability means assembling the monitoring, testing, lineage and alerting you need from projects whose source code you can read, modify and run yourself, rather than buying one platform that does all of it. It is a real option and plenty of good teams take it. It is also more assembly than the phrase suggests, because no single open source project covers the whole surface.
Before the list, one boundary, because getting it wrong is the most common mistake in this category. Data observability watches the data. Application and infrastructure observability watches the systems that move the data. They use the same word and they solve different problems. A tool that tells you your Airflow worker used too much memory will not tell you that the worker succeeded and wrote thirty thousand rows where it usually writes three million. OpenTelemetry documentation is explicit about what it is and is not:
"OpenTelemetry is not an observability backend itself."
Both kinds belong in a mature stack. Only one of them answers the question this article is about, and the entries below say which is which.
Ten of these are open source or source available projects you would run yourself. The first is the managed platform they are usually measured against, included because the comparison is the decision. Every license, release date and commit date below was read from the project own repository, package index or documentation on 5 September 2026. None of it is quoted from another article, and no project is hyperlinked; the URLs are written out so you can go and check them yourself.
| Tool | License today | Covers | Does not cover |
|---|---|---|---|
| 1. Decube | Commercial, managed | Freshness, volume, schema drift, field health, custom SQL and group by monitors, incident management with lineage impact, catalog, glossary, governance and access policies | It is not open source, you cannot read or fork the code, and it has a floor price |
| 2. GX Core (Great Expectations) | Apache 2.0 | Expressive assertions about data, run as code, with generated documentation of the results | No scheduler, no alert routing, no incident history, no lineage, no anomaly detection |
| 3. Soda Core | Elastic License 2.0 | Data quality and data contract verification in YAML, 50 or more built in checks, via a CLI or Python API | Anomaly detection, dashboards and central management sit in Soda Cloud, and the license forbids offering the software as a hosted service |
| 4. Elementary OSS | Apache 2.0 | dbt native monitoring: test results, basic anomaly detection, table level lineage, a self hosted report, alerts to Slack and Microsoft Teams | Requires dbt. Machine learning anomaly detection, column level lineage, incident management, catalog, SSO and SOC 2 are Elementary Cloud |
| 5. OpenMetadata | Apache 2.0 | Catalog, profiler, no code quality tests, incident management, lineage, alerts and notifications, all in the open source project | You operate four services yourself. Collate is the managed commercial version |
| 6. DataHub | Apache 2.0 | Metadata platform, catalog, lineage, governance, and a large connector library | Freshness assertions are part of the DataHub Cloud Observe module, not open source DataHub |
| 7. OpenLineage and Marquez | Apache 2.0 | An open standard for collecting lineage metadata, and a reference server that stores and visualizes it | Neither one monitors data or raises incidents. Marquez has had no tagged release since March 2025 |
| 8. ODD Platform | Apache 2.0 | Data discovery and observability in one self hosted application, with a catalog and a collector based ingestion model | A smaller community than OpenMetadata or DataHub, so fewer connectors and fewer answered questions |
| 9. Deequ | Apache 2.0 | Unit tests for data on very large datasets, including constraint suggestion and metric storage, as a library | Requires Apache Spark and a version matched artifact. No UI, no alerting, no lineage |
| 10. OpenTelemetry | Apache 2.0 | Generating, exporting and collecting traces, metrics and logs from your applications and infrastructure, vendor neutrally | It is not data observability and it is not a backend. It does not test data, check freshness or count rows |
| 11. ELK Stack | AGPL v3, SSPL v1 and Elastic License 2.0 | Centralized log ingestion, indexing, search and visualization for the systems running your pipelines | Same boundary as above. It watches the jobs, not the tables. The licensing is also the most complicated in this list |
Decube is the managed option in this list and the one the others get compared against, so it belongs at the top rather than buried at the bottom as a sales pitch. It is a single platform covering observability, catalog, lineage and governance, and its architecture is metadata only, which means the platform reads metadata about your tables rather than copying the data itself. That last point is usually the reason a security team asks about self hosting in the first place, so it is worth knowing that it is not always the answer.
Its prices are published, which is unusual here and is what makes the cost comparison below possible. What it does not offer is the thing this article is about: you cannot read the source, you cannot fork it, and there is a minimum spend.
GX Core is the best known open source data quality framework and the one every competing article names. It is a Python library that lets you write expectations, which are readable assertions about a dataset, group them into suites, and run them against a batch of data through a checkpoint. It generates human readable documentation of every validation run, which is genuinely useful when somebody asks what you checked and when. The current release is 1.22.0, published 31 August 2026, and the license in the repository is Apache 2.0. The package index confirms the same.
One thing has changed that the other articles have not noticed. The repository at github.com/great-expectations/great_expectations now redirects to github.com/fivetran/great_expectations, and on 13 May 2026 Fivetran announced it would become steward of the Great Expectations open source community and the GX Core project, saying GX Core "will continue as an open source, community-driven project". That is a stated commitment rather than a guarantee, and it is the sort of thing worth knowing before you build a data quality program on top of it. The project website is greatexpectations.io.
What GX Core does not give you is everything around the test. There is no scheduler, so your orchestrator runs it. There is no alert routing, so you write the integration. There is no incident history, no lineage and no anomaly detection, so a test only ever catches a problem somebody already imagined. That last limit is the real one: expectations are excellent at the failures you predicted and blind to the ones you did not.
Soda Core is a data quality and data contract verification engine. You define checks in YAML, which is the friendliest syntax in this list for someone who is not a Python engineer, and run them from a CLI or a Python API against PostgreSQL, Snowflake, BigQuery, Databricks, DuckDB and a long list of others. Its own README describes more than 50 built in checks. The current release is 4.23.0, published 1 September 2026, and the project is actively developed. The website is soda.io.
The license is where you need to pay attention, and it is the fact this article exists to surface. The LICENSE file on the main branch of the Soda Core repository today is the Elastic License 2.0. That license permits use, copying, distribution and modification, but it forbids providing the software to third parties as a hosted or managed service, and it forbids moving, changing, disabling or circumventing the license key functionality. It is a source available license, not an OSI approved open source one. At tag v3.3.20 the same file was the Apache License 2.0, and the Python package metadata for soda-core 4.23.0 declares its license as Proprietary. The last version 3 release reached the package index on 24 September 2025 and the first version 4 release on 28 January 2026, which places the change between those two dates.
Soda own installation documentation also lists a Soda Cloud account among the requirements for using Soda, and explains that in version 4 the free and paid packages are no longer distinguished by name as they were in version 3 but by which installation flow you use, with the licensed extensions served from an authenticated private package index. None of this makes Soda a bad tool and the YAML check syntax is genuinely good. It does mean that if your reason for self hosting is license freedom, this is not the project you thought it was in 2024.
Elementary is the strongest option in this list if, and only if, your transformations run in dbt. Its own documentation is direct about what the open source package is:
"a CLI tool that works alongside the Elementary dbt package"
The open source package reads the metadata, artifacts and test results that dbt produces, generates an observability report you host yourself, surfaces anomalies and failed tests, sends alerts to Slack and Microsoft Teams, and tracks model and test performance over time. It is Apache 2.0 and actively maintained, with the most recent Python release on 8 July 2026. The project is at elementary-data.com.
The open source and cloud split is published by Elementary itself and is worth reading before you commit. Open source covers dbt test results, basic anomaly detection, table level lineage, test coverage visibility, model performance and basic alerting. Elementary Cloud is where machine learning anomaly detection, column level lineage up to the BI layer, no code tests, data contracts, incident management, the catalog, role based access control, single sign on, and SOC 2 Type II and HIPAA compliance sit. If any of those last items is a requirement rather than a preference, the open source package is not the thing you are choosing between.
OpenMetadata is the most complete genuinely open source answer in this list. It is Apache 2.0, it is developed hard, with releases 2.0.0, 1.13.4, 2.0.1 and 1.13.5 all published in the two weeks to 3 September 2026, and unlike DataHub it keeps its data quality and observability features in the open source project rather than reserving them for a paid tier. You get a catalog, a data profiler, no code quality tests, observability alerts and notifications, incident management and lineage in the software you download. The project is at open-metadata.org, and Collate is its managed commercial version.
The cost is operational rather than financial, and it is concrete. OpenMetadata own quick start pulls four Docker images: the server, a MySQL or PostgreSQL database, Elasticsearch, and the ingestion container running Airflow. The same page states that you must allocate at least 6 GiB of memory and 4 vCPUs to Docker to run it. That is the local development minimum, not a production sizing, and production means you own the upgrades, the search index, the database backups and the ingestion scheduler. If you are comparing effort honestly, this is the entry to compare against.
DataHub is the other large open source metadata platform, Apache 2.0, originally built at LinkedIn and now developed at a fast pace, with version 1.7.0.1 published on 3 September 2026. As a catalog and lineage layer with a very large connector library it is excellent, and if you already run it, adding quality signals on top of it is a reasonable plan. The project is at datahub.com.
For observability specifically, read the availability notices in the documentation before you plan around it. DataHub own documentation states that the freshness assertions feature "is available as part of the DataHub Cloud Observe module of DataHub Cloud". The same pattern applies across the Observe assertion set. That is a legitimate business model and DataHub is transparent about it, but it means DataHub answers the catalog question in open source and the observability question in its paid product.
OpenLineage is an open standard for collecting lineage metadata, and Marquez is the reference implementation that stores and visualizes what the standard collects. Both are Apache 2.0. OpenLineage is developed continuously, with release 1.53.0 published on 1 September 2026. They are at openlineage.io and marquezproject.ai.
Two things to be clear about. Neither project monitors data or raises an incident; they record and display where data came from and where it went, which is one capability of the five you need, not a stack. And Marquez maintenance is uneven: the most recent tagged release, 0.51.1, is dated 27 March 2025, although commits continued through 2 September 2026. Seventeen months without a release is not abandonment, but it is a signal worth weighing if you were planning to depend on it for regulated lineage evidence.
ODD Platform, from the Open Data Discovery project, is a self hosted data discovery and observability application under the Apache 2.0 license. It is the least known entry here and it is genuinely maintained: version 0.29.0 was released on 26 June 2026 and commits landed as recently as 5 September 2026. It is at opendatadiscovery.org, and there is a public demo instance if you want to see it before installing anything.
Its honest disadvantage is community size. OpenMetadata and DataHub have thousands more contributors and users between them, which in practice means more connectors, more answered questions and faster fixes. If the connector you need exists, ODD is a lighter thing to operate than either. If it does not, you are writing it.
Deequ is an Amazon library that its README describes as unit tests for data, built on Apache Spark and aimed at measuring data quality in very large datasets. It is Apache 2.0, actively maintained, with release 2.0.21 on 18 June 2026, and PyDeequ gives it a Python interface. If your data volumes are big enough that running checks outside Spark is impractical, Deequ is the right tool and nothing else in this list is close.
It is a library, not a platform. There is no interface, no alerting and no lineage, and it requires Java 8 and an artifact matched to your exact Spark version, which the README documents version by version. You are getting a very good measurement engine and building everything around it.
OpenTelemetry deserves a place in your stack and a correction about what it does. It is an Apache 2.0, vendor neutral framework for generating, exporting and collecting traces, metrics and logs, and instrumenting your pipelines with it is a good idea. Its documentation is at opentelemetry.io.
It is not data observability. It tells you that your ingestion job ran for eleven minutes and used four gigabytes. It does not tell you that the job succeeded and loaded a tenth of the usual rows, that a nullable column started arriving empty, or that a currency field silently changed unit. Those are data questions and OpenTelemetry does not ask them. It also, by its own documentation, is not a backend at all, so you still choose and operate somewhere to store and query what it collects.
The ELK Stack, also carried over, is Elasticsearch for indexing and search, Logstash for ingestion and processing, and Kibana for visualization. It is the standard answer for centralized logging and it is genuinely good at it, which matters when you are debugging why a pipeline failed at three in the morning.
Two caveats. The first is the same boundary as above: it observes the systems, not the data. The second is licensing, which is the most complicated in this list and is often described wrongly. The license file in the Elasticsearch repository states that its source is covered by a triple license under the GNU Affero General Public License v3.0 only, the Server Side Public License v1, and the Elastic License 2.0. Kibana carries the same triple license. Logstash is Apache 2.0 outside its x-pack directory and under the Elastic License inside it. If you are choosing open source for a legal reason rather than a budget one, have someone read those files rather than a summary of them. Elastic is at elastic.co.
Both of these appear in top ten lists published in 2026, one of them at number four. Neither should be the foundation of anything you are building now. This is what happens when a list is compiled from other lists instead of from the repositories.
Apache Griffin was a data quality solution for big data covering both streaming and batch modes. Its GitHub mirror was archived by its owner on 24 November 2025 and is now read only, and its last release, 0.6.0, is dated 9 November 2020. The Apache Attic retirement page states the position plainly:
"Griffin became a Top Level Project in November 2018, retired in September 2025 and the move to the Attic was completed in November 2025."
A project in the Attic receives no releases, no security fixes and no support. Nothing about Griffin was bad; it simply has no maintainers, which is the one thing that matters when you are choosing software you intend to run for years.
re_data was a dbt based reliability toolkit and a reasonable choice at the time. Its last release, 0.11.0, is dated 27 December 2023 and its most recent commit is dated 30 April 2024. It is not archived and nobody has declared it dead, which is precisely why it keeps appearing in lists. Two and a half years without a release, in a category where warehouse connectors and dbt itself change every quarter, is the answer. Elementary covers the same ground and is maintained.
The generic version of this list applies to all open source software and helps nobody. Here is what each point actually means when the software in question is watching your data.
Nobody publishes a credible average for this, so here is arithmetic you can do with your own numbers instead of a statistic you would have to take on trust.
Decube publishes its prices. As read on 5 September 2026, the Starter plan is 175 US dollars per user per month with an annual subscription from 21,000 dollars a year and a minimum of ten users, covering up to three data sources and 1,000 monitors. The Growth plan is 225 dollars per user per month from 54,000 dollars a year with a minimum of twenty users, covering up to ten sources and 3,000 monitors. Enterprise is quoted. Additional monitors are 59 cents each and an extra data source is 100 dollars a month. You can check all of it on the Decube pricing page.
Take the entry figure of 21,000 dollars a year and divide it by your fully loaded cost per engineer hour. At 100 dollars an hour, the managed platform has to save your team about 210 engineering hours a year, which is roughly four hours a week, before it is the cheaper option. At 60 dollars an hour it has to save about 350 hours, or seven hours a week. That is the whole calculation, and the only honest question left is how many hours the work below actually takes you.
Here is the work, taken from the projects own deployment documentation rather than estimated.
| What you take on | What that means in practice |
|---|---|
| Running the services | OpenMetadata is four containers: server, MySQL or PostgreSQL, Elasticsearch and the Airflow ingestion service, with a stated minimum of 6 GiB memory and 4 vCPUs for a local Docker deployment. Production adds high availability, backups and index management. |
| Building what the tool omits | GX Core has no scheduler, no alert routing and no incident history. You supply the orchestration, the results storage, the notification integration and the on call workflow. |
| Writing the checks | Freshness, volume, schema and distribution monitors are configuration in a managed platform and code in most open source ones. Every table you add is more of that code. |
| Keeping the joins working | A typical open source stack is two or three projects plus dbt plus your warehouse. Each upgrade of any one of them is a compatibility check on all the others. |
| Upgrades and security patches | You track releases and CVEs for every component. Both large metadata platforms in this list shipped multiple releases in the past fortnight alone. |
| Project risk | License changes, ownership changes and retirements are your problem to detect and your problem to migrate away from. Three of the projects here demonstrated one of the three inside twelve months. |
| Evidence for auditors | If a regulator asks who approved a data change and what it affected, you build the reporting that answers it. Certifications such as SOC 2 belong to the paid tier in several of these projects, not to the open source package. |
Decube is a managed platform that integrates with an organization existing data ecosystem and monitors the health and performance of the data inside it. Unlike an open source stack it is fully managed and independently certified, and it brings data observability together with data contracts and data catalog features in one product rather than three you assemble. You can see the platform on the Decube data observability page.
The clearest way to see what the managed side removes from your plate is the monitor question. Choosing which monitors to run on which tables is a design decision in every stack, open source or not. The video below walks through each monitor type in Decube and how to choose between them: schema drift and job failure, which switch on automatically when a source is connected; freshness, which learns each table own update pattern so it does not fire noisily; volume, which watches row count behavior; field health, which validates at column level with null, uniqueness and regular expression checks; custom SQL for cross table business rules; and group by, which segments a check by a dimension such as region so you can see where quality breaks rather than only that it did.
A managed platform costs money and there is a floor to it. Decube entry plan starts at 21,000 US dollars a year with a minimum of ten users, so a three person data team watching a handful of tables is paying for capacity it does not need. That is a real limitation and no amount of feature comparison makes it go away.
Some large organizations will build instead, and should. Companies operating at the scale of Netflix or Airbnb, with extraordinary data volumes and heavily customized internal tooling, generally run home grown observability because nothing off the shelf fits their architecture. Their constraint is not budget, it is fit.
And a managed platform is a dependency. You cannot read the code, you cannot fork it, and your monitoring availability is somebody else operational responsibility rather than yours. For some teams that is the point. For others it is disqualifying, and both positions are defensible.
The decision comes down to five conditions. Count how many are true of your team, and be honest about the fourth.
| If this is true of you | Then |
|---|---|
| Your data lives in one warehouse, your transformations run in dbt, and you have fewer than a few hundred tables | Self host. Elementary OSS is built for exactly this shape and will cover you for a long time. |
| Your volumes are large enough that checks have to run inside Spark | Self host with Deequ. Nothing managed will beat it on that specific job. |
| You want a catalog and lineage as well as monitoring, and you have an engineer who can own four services | Self host OpenMetadata. It is the most complete genuinely open source answer in this list. |
| A regulator, an auditor or an enterprise customer asks you for certified evidence | Buy. SOC 2 and similar certifications sit in the paid tier of several of these projects, not in the open source package, and building the evidence trail yourself is the expensive part. |
| Nobody on the team has four spare hours a week, every week, to keep the stack working | Buy. That is the arithmetic in the cost section, and four hours a week is the honest floor for a multi component stack rather than a worst case. |
Three of those five point at open source, and we sell the alternative. That is the accurate answer, and pretending otherwise would not survive your first month of running either one. What we would ask is that you check the license file and the last commit date of anything you adopt, because this article found a source available license described as open source, a repository under new ownership and a retired Apache project in a single afternoon of checking. If you would rather not repeat that exercise every year, that preference is itself a legitimate reason to buy, and you can request a Decube demo when you get there.
For a dbt based stack, Elementary OSS is the strongest fit, because it reads dbt artifacts directly and gives you a report, basic anomaly detection and Slack alerts under an Apache 2.0 license. For a full catalog plus quality plus lineage platform, OpenMetadata is the most complete genuinely open source option, because it keeps its quality and observability features in the open source project rather than in a paid tier. For code first testing, GX Core is the most widely used framework. For very large datasets that must be checked inside Spark, Deequ is the right library. Check two things before adopting any of them: the license file in the repository, which is not always what a listicle says it is, and the date of the most recent release and commit.
The software is free and the stack is not. You take on running the services, building what the tool omits, writing the checks, keeping the components compatible as they upgrade, patching them, and producing audit evidence yourself. As a concrete example, the OpenMetadata quick start pulls four services and states a minimum of 6 GiB of memory and 4 vCPUs for a local Docker deployment alone. The useful way to size it is arithmetic: take the license cost you would otherwise pay, divide by your fully loaded engineer cost per hour, and ask whether the work above takes more or less than that many hours a year.
If you run dbt, start with Elementary OSS and pay nothing. If you do not run dbt but you have a Python engineer, start with GX Core and accept that you are supplying the scheduler, the alerts and the incident history. Only move to a managed platform when one of three things becomes true: nobody has four consistent hours a week to maintain the stack, an auditor or an enterprise customer asks you for certified evidence, or the number of tables has grown past the point where hand written checks cover them. Managed platforms in this category carry seat minimums, so a very small team is usually paying for capacity it will not use.
For a mid market team, the deciding factor is usually whether you need a catalog and lineage alongside monitoring, and whether anyone will ask you for certified evidence. If the answer to both is no and you run dbt, Elementary OSS is enough. If you want the catalog too and you have an engineer who can own four services in production, OpenMetadata covers it under Apache 2.0. If you need observability, catalog, lineage and governance in one place with SOC 2 and ISO 27001 behind it, that is where a managed platform such as Decube fits, and the honest threshold is whether your team can spare roughly four hours a week indefinitely to run the alternative.
On the open source side, the real alternatives are OpenMetadata for a complete catalog and quality platform, Elementary OSS for dbt based stacks, GX Core for code first data testing, Soda Core for YAML defined checks and data contracts, and Deequ for Spark scale validation. Be aware that Soda Core repository license is the Elastic License 2.0 rather than an OSI approved open source license, and that DataHub freshness assertions sit in its paid Cloud Observe module rather than in the open source project. On the managed side, Decube covers observability, catalog, lineage and governance in one platform with published pricing, which makes the comparison easier than it usually is in this category.
Managed data observability is usually priced per user per month on an annual subscription, with a seat minimum, and then sized by two capacity dimensions: how many data sources you connect and how many monitors you run. Decube publishes both. As of 5 September 2026 its Starter plan is 175 US dollars per user per month from 21,000 dollars a year with a minimum of ten users, covering up to three data sources and 1,000 monitors, and its Growth plan is 225 dollars per user per month from 54,000 dollars a year with a minimum of twenty users, covering up to ten sources and 3,000 monitors. Overage is charged per monitor and per additional source. To size your own requirement, count your connected systems and the tables you actually need monitored, not your total table count.
We cannot verify any ranking attributed to Gartner, because gartner.com does not serve its research to public requests, so any list you find on a vendor blog claiming to be the Gartner ranking is that vendor paraphrasing something you cannot check. A more useful test is one you can run yourself in ten minutes per tool: read the license file in the repository, look at the date of the most recent release and the most recent commit, and read the vendor own documentation for which features sit in the free package and which sit in the paid cloud. That test is how this article found that one widely recommended project had moved to a source available license and another had been retired to the Apache Attic.
No. OpenTelemetry is an application and infrastructure observability framework for generating, exporting and collecting traces, metrics and logs, and its own documentation states that it "is not an observability backend itself". It tells you how the systems moving your data behaved. It does not tell you whether the data those systems produced is fresh, complete, correctly shaped or the right size, which is what data observability means. The same distinction applies to the ELK Stack. Both belong in a mature platform and neither answers a data quality question.
First step to AI Readiness
Table of Contents
Sneak peek from the data world.
Bring lineage, quality, governance, and AI together in one platform—so your teams and AI agents can act with confidence.
_For%20light%20backgrounds.svg)
.svg){kind=small}
.webp)