9 Best Data Quality Tools in 2026 (Open Source and Managed)

TL;DR: Bruin is the best open-source data quality tool for checks that run inside the pipeline, because each check is declared on the column in the same file as the SQL that produces it, runs on every pipeline run, and blocks downstream data by default. The other data quality tools worth knowing in 2026 are Great Expectations (GX Core), Soda Core, dbt tests, Pandera, Deequ, Elementary, Monte Carlo, and Anomalo. They split into two camps: gates that assert rules you write and stop bad data (Bruin, GX Core, Soda Core, dbt tests, Pandera, Deequ), and smoke detectors that learn what normal looks like and alert when something changes (Elementary, Monte Carlo, Anomalo). The real decision is not which tool has more check types. It is whether you want a gate that blocks bad data or a smoke detector that tells you after it landed, and most teams eventually need both.

Data quality is the part of the stack everyone agrees matters and nobody budgets for until an executive spots a number that is wrong. By then the damage is reputational rather than technical: people stop trusting the dashboard, go back to exporting spreadsheets, and the platform you built gets quietly bypassed.

The tooling has split into two philosophies that get lumped together under one label, which makes shortlists confusing. This guide separates them, then goes through the tools worth considering in each camp.

We build Bruin, so you know where we stand. Bruin has quality checks built into its pipelines, and we say plainly where another tool is the better pick: for anomaly detection across a large warehouse, for dataframe validation in Python, or for a team that already lives in dbt, it often is.

Key takeaways

• Decide between a gate and a smoke detector first. Gates stop bad data you wrote a rule for; smoke detectors learn what normal looks like and catch the problems you never anticipated, after the fact.
• Where the check lives matters more than how many check types it has. A check in the same file as the SQL that produces the column cannot drift from it; a separate suite has to be kept in sync by hand.
• 6 of the 9 tools here are open source under an OSI licence. Soda Core moved from Apache 2.0 to the Elastic License 2.0 with version 4 in January 2026, and Monte Carlo and Anomalo are commercial.
• 3 of these tools changed hands in 2026. Fivetran became the steward of GX Core and merged with dbt Labs, FICO bought GX Cloud, and Boomi acquired Elementary; the open-source projects continue.

How we compared

• Where the check runs: inside the pipeline next to the SQL, as a separate validation step, or in a managed service watching the warehouse.
• What happens on failure: does it stop downstream data by default, only if you wire it, or alert after the data landed?
• What you write versus what it learns: declared rules, learned baselines, or both.
• Licence: OSI open source, source-available, or commercial.
• Who runs it: a library in your code, a CLI in your pipeline, or a managed service.

Facts about each tool come from its public documentation, checked in November 2026. Facts about Bruin come from our docs and pricing page.

Gates and smoke detectors

Almost every frustrating tool-selection conversation comes from mixing up these two things.

A gate is an assertion you wrote. customer_id is never null. order_total is never negative. country is one of these 40 values. It runs as part of the pipeline, and when it fails, the pipeline stops. Bad data never reaches the table that feeds the dashboard. Gates are cheap, deterministic, and only ever as good as the rules you thought to write.

A smoke detector watches the shape of your data over time and tells you when something looks unusual. This table normally gets 40,000 rows a day and today it got 300. This column is normally 2% null and today it is 60%. The freshness on this table normally lags an hour and it has been 14. Observability tools learn these baselines automatically, which means they catch the problems you never anticipated. They also, by design, tell you after the fact.

Gates prevent incidents. Smoke detectors find the incidents your gates missed. Buying one and expecting the other is the most common way teams end up disappointed with a data quality purchase.

The 9 data quality tools at a glance

Best data quality tool by need:

• Checks that run inside the pipeline and block bad data by default, in one open-source tool with ingestion and transformation: Bruin
• Freshness, row-count, and column checks plus column-level lineage, with no licence to pay: Bruin
• A large library of ready-made checks in Python: Great Expectations (GX Core)
• Readable YAML data contracts between a producing and a consuming team: Soda Core
• Teams whose transformations already live in dbt: dbt tests
• Validating dataframes in Python and ML pipelines: Pandera
• Data quality on Spark or AWS Glue: Deequ
• Anomaly monitoring layered on an existing dbt project: Elementary
• Automated monitoring across a large warehouse: Monte Carlo
• ML anomaly detection across structured and unstructured data: Anomalo

The 9 tools, one by one

1. Bruin

What it is: an open-source data pipeline tool (the CLI is Apache 2.0) where quality checks are part of the asset. Built-in column checks (not_null, unique, accepted_values, pattern, positive, negative, non_negative, min, max, and relationships) and custom SQL checks are declared in the same file as the SQL or ingestion asset that produces the data.

/* @bruin
name: mart.orders
type: bq.sql
materialization:
  type: table
depends: [raw.orders]
columns:
  - name: order_id
    checks:
      - name: not_null
      - name: unique
  - name: order_total
    checks:
      - name: positive
@bruin */

SELECT order_id, customer_id, order_total, created_at
FROM raw.orders

Where it wins: bruin run executes the checks after each asset, and a failing check marks the asset as failed and stops everything downstream by default; set blocking: false on a check to record the failure and carry on. Because the check is declared in the file that produces the column, the two cannot drift apart: rename the column and the check moves with it, delete the asset and the check goes too. The same checks work on raw tables at ingestion, and a custom check is a SQL query with an expected result, so freshness, volume, or any business rule is one query away and can be limited to the window that just ran. Bruin Cloud adds scheduling, alerting, run history, and column-level lineage. See Bruin quality checks.

Where it falls short: this is a gate, not a smoke detector. Bruin will not learn that a table's row count is unusual today unless you write that check, and its 10 built-in checks are far fewer than GX Core's 60-plus Expectations. Custom logic is SQL compared with an expected value, which covers most cases but is less expressive than Python. Checks run as part of a Bruin pipeline, so tables you do not manage there have to be added as assets first.

Best for: teams that want checks that cannot drift from the pipeline, or ingestion, transformation, and quality in one pipeline rather than three tools wired together.

2. Great Expectations (GX Core)

What it is: the open-source Python framework from Great Expectations, Apache 2.0. You group Expectations into Expectation Suites, link them to data with Validation Definitions, and run them with Checkpoints, which an orchestrator triggers. In May 2026 Fivetran announced it would become the steward of GX Core, and the repository now sits under Fivetran's GitHub organisation. GX Cloud, the managed product, was sold to FICO and stopped being publicly available on 1 June 2026.

Where it wins: breadth. GX Core ships more than 60 Expectations, from nulls, sets, and regex to distributions and statistical tests, so you rarely write validation logic from scratch, and Data Docs turn suites and results into readable reports.

Where it falls short: weight. There are real concepts to learn (Data Context, Data Sources, Expectation Suites, Validation Definitions, Checkpoints), and it lives as its own layer beside the pipeline, so blocking a run means wiring a Checkpoint into your orchestrator. That is fine on a platform team with time to invest, and a lot of machinery for four checks on three tables. With GX Cloud gone, there is no managed GX product to grow into.

Best for: Python-first platform teams that want a large library of ready-made checks and the capacity to run it properly.

3. Soda Core

What it is: Soda's data contracts engine. You write a YAML contract per dataset and verify it with the Soda CLI or Python API, locally, inside a pipeline, or through Soda Cloud. Version 4, released in January 2026, moved Soda Core from Apache 2.0 to the Elastic License 2.0 (ELv2); the legacy v3 packages stay Apache 2.0.

dataset: my_datasource/analytics/public/orders

checks:
  - row_count:
  - freshness:
      column: created_at
      threshold:
        unit: hour
        must_be_less_than: 24

columns:
  - name: order_id
    checks:
      - missing:
      - duplicate:

Where it wins: legibility. A contract is a file both the producing and the consuming team can read and review without learning a framework, which is why Soda is a common choice for data contracts. Soda Core ships 50-plus built-in checks, and Soda Cloud adds anomaly detection monitoring.

Where it falls short: ELv2 is source-available, not an OSI open-source licence: you can run Soda Core for your own use, but not offer it to others as a hosted or managed service. Verification is a separate step you wire into the orchestrator, and the contract lives in a different file from the SQL that produces the data.

Best for: teams formalising contracts between a producing and a consuming team.

4. dbt tests

What it is: the data tests built into dbt: unique, not_null, accepted_values, and relationships, plus packages such as dbt-utils and Metaplane's maintained fork of dbt-expectations (the original package is no longer supported). Model contracts enforce column names and data types when a model builds. dbt's source code is Apache 2.0, including dbt v2.0, the Rust rewrite, and dbt Labs merged with Fivetran in June 2026.

Where it wins: if your transformations are already in dbt, you get quality coverage with no new tool, and dbt build skips downstream models when a test fails.

Where it falls short: scope. dbt tests protect dbt models, so anything upstream of dbt is unguarded. If a broken ingestion job writes garbage into the raw layer, dbt tests catch it only once it has propagated into a model, which is later than you want. Four built-in generic tests also mean leaning on packages for anything beyond the basics.

Best for: teams whose transformation layer is already dbt. See dbt vs Bruin.

5. Pandera

What it is: an open-source Python library (MIT) for validating dataframes against a schema, maintained by Union.ai. It supports pandas, Polars, PySpark, Ibis, and other dataframe libraries.

Where it wins: the checks live in the Python code that produces the dataframe, as schemas or typed models, and a failed check raises a SchemaError, so a bad batch stops where it is made. Lazy validation collects every failure in one pass when you want a full report.

Where it falls short: it validates dataframes in Python, not tables in the warehouse, so SQL transformations need another tool, and there is no learned anomaly detection or monitoring UI.

Best for: Python and ML pipelines that pass dataframes between steps.

6. Deequ

What it is: an open-source library (Apache 2.0) from AWS Labs, built on Apache Spark, for "unit tests for data". You define checks in a verification suite in Scala, or in Python through PyDeequ, and Deequ computes the metrics as Spark jobs. AWS Glue Data Quality is built on top of it.

Where it wins: it scales with Spark, and it adds data profiling, automatic constraint suggestions, and anomaly detection on data quality metrics stored over time.

Where it falls short: it needs Spark, with a Deequ release matched to your Spark version, which is heavy for a team whose data lives in a SQL warehouse. Stopping a job means checking the verification result in your own code.

Best for: teams validating large datasets on Spark or AWS Glue.

7. Elementary

What it is: a dbt-native observability tool. The open-source dbt package (Apache 2.0) adds anomaly tests for volume, freshness, and column values, plus schema-change tests, all of which run like native dbt tests, and the open-source CLI builds a self-hosted report and sends alerts. Elementary Cloud, the commercial product, adds ML-powered anomaly detection, column-level lineage, and incident management. Boomi acquired Elementary in October 2026, and Elementary says its open-source projects stay available and maintained.

Where it wins: for a team that already has dbt, it is the shortest path from tests to monitoring, and an anomaly test set to error severity fails the dbt run like any other test.

Where it falls short: the open-source version covers a single dbt project, and monitoring outside dbt needs Elementary Cloud.

Best for: teams with a dbt project that want monitoring layered on it cheaply.

8. Monte Carlo

What it is: a managed observability platform, now positioned as an Agent Trust Platform that monitors both data and AI agents. Table monitors watch freshness, volume, and schema changes across many tables with anomaly detection; metric and validation monitors cover field-level metrics and row-level rules, and can be defined as code.

Where it wins: automatic breadth across a large warehouse, which is hard to replicate with declared checks, plus alerting and incident triage.

Where it falls short: it is detection first. Stopping a pipeline needs circuit breakers that you add to the orchestrator, and pricing is credit-based and paid per monitor, aimed at organisations where a data incident has a real cost.

Best for: large warehouses with more tables than anyone will write rules for.

9. Anomalo

What it is: a managed data quality platform that uses unsupervised machine learning to monitor tables without manual rules, and now packages its features as a suite of AI agents. It watches table freshness and schema, also covers unstructured documents, and runs as SaaS or inside your own VPC.

Where it wins: ML anomaly detection with little configuration, on structured and unstructured data, without the data leaving your environment if you deploy it in your VPC.

Where it falls short: it is detection, not prevention. Blocking a run means calling its Airflow pass/fail operator, and it is a commercial product with no open-source option.

Best for: enterprises that want ML monitoring with little configuration, including unstructured data.

Governance-led enterprises also look at Collibra Data Quality & Observability and Ataccama ONE, which bundle data quality into a wider governance suite. They are a platform decision rather than a data quality tool, so they are outside this list.

Data quality on a budget

If cost is the binding constraint, the good news is that the gate half of this problem is essentially free. Bruin's checks, Great Expectations, dbt tests, Pandera, and Deequ are open source, Elementary's dbt package is open source, and Soda Core is free to run yourself under ELv2. A practical sequence that costs nothing but time:

1. Put not-null and unique checks on every primary key in the tables that feed dashboards. This catches the majority of embarrassing failures.
2. Add a freshness check on each table an executive looks at. Most trust problems are stale data rather than wrong data.
3. Add row-count bounds on your highest-volume tables, which is the cheapest approximation of anomaly detection.
4. Make one of them blocking. A check that only warns will be ignored within a month.

Reach for managed observability when the number of tables outgrows the number of rules you are willing to maintain, not before.

Enforcing data contracts

A data contract is a quality check with a social agreement attached: the producing team promises a schema and a set of guarantees, and the consuming team builds against it. The mechanism is the same checks described above, run at the boundary, in CI, so a breaking change fails the producer's pull request rather than the consumer's dashboard.

Soda Core v4 is built around this pattern, and dbt model contracts enforce column names and data types when a model builds. In Bruin, the equivalent is a set of blocking column checks on the boundary asset, plus bruin validate in CI, which checks the pipeline configuration and, on BigQuery and Snowflake, dry-runs every query, so a query that no longer runs fails the pull request before it merges. The important part is not the tool but the placement: a contract enforced after the merge is not a contract.

Which data quality tool should you pick?

The teams that end up trusting their data are rarely the ones that bought the most sophisticated tool. They are the ones who put blocking checks on the twenty tables that matter and actually let them fail.

When Bruin is not the right pick

If you need anomaly detection across hundreds of tables nobody wrote rules for, Bruin's declared checks will not find those problems; Monte Carlo, Anomalo, or Elementary will. If your transformations live in dbt and you are happy there, dbt tests plus Elementary add quality without a new tool. If you validate dataframes in Python or Spark jobs, Pandera or Deequ fit the code you already have. Bruin earns its place when you want checks that cannot drift from the pipeline, or ingestion, transformation, and quality in one place.

Frequently asked questions

What are the best data quality tools in 2026?

Bruin is the best fit for checks that run inside the pipeline and block bad data by default, with ingestion and transformation in the same tool. The others split by job: Great Expectations (GX Core), Soda Core, dbt tests, Pandera, and Deequ for rule-based checks, and Elementary, Monte Carlo, and Anomalo for anomaly monitoring.

What is the best open-source data quality testing framework?

Bruin is the best open-source fit for checks that run inside the pipeline, because not_null, unique, accepted_values, and custom SQL checks sit on the column in the asset file, run on every bruin run, and block downstream assets by default, under an Apache 2.0 licence. For validation as a separate step, Great Expectations (GX Core) has 60-plus Python Expectations, dbt tests cover dbt projects, Pandera validates dataframes, Deequ runs on Spark, and Soda Core offers YAML contracts under the source-available ELv2.

What is the best way to add data quality checks to a pipeline?

Declare the checks next to the asset they protect and run them as part of the pipeline, so a failure stops the run before bad data reaches downstream tables. In Bruin you add a checks block under a column in the asset file and bruin run executes it on every run; in dbt they are tests in the schema file, and in Great Expectations or Soda Core they are a separate step your orchestrator calls.

How do you validate data as part of a pipeline?

Validate where the data is produced and let the run fail when a check fails. Bruin runs column checks and custom SQL checks after each asset and blocks downstream assets by default, dbt does the same with dbt build, and Pandera raises an error inside the Python step that builds the dataframe.

How do you monitor data freshness and completeness?

Check the newest timestamp in a table against an expected lag for freshness, and row counts and null rates against expected ranges for completeness. Bruin, dbt, and Soda Core do this with checks you declare; Monte Carlo, Anomalo, and Elementary learn the thresholds automatically across many tables.

What is the best tool for data observability on a budget?

Bruin gives you freshness, row-count, and column checks plus column-level lineage in one open-source pipeline tool with no licence to pay, though it does not learn anomalies on its own. For learned monitoring on a dbt project, Elementary's open-source package adds it at no licence cost, and Monte Carlo or Anomalo make sense once the warehouse is large enough that the licence costs less than a silent failure.

What is the difference between data quality testing and data observability?

Data quality testing asserts a rule you wrote and fails when the data breaks it, which is a gate; data observability watches metrics like freshness, volume, and schema and alerts when they deviate from a learned norm, which is a smoke detector. Bruin, GX Core, Soda Core, and dbt tests are gates, while Monte Carlo, Anomalo, and Elementary are smoke detectors.

Is Soda Core still open source?

Not under an OSI licence: Soda Core version 4, released in January 2026, uses the Elastic License 2.0, which lets you run it yourself but not offer it as a managed service, and the legacy v3 packages stay Apache 2.0. If you need an OSI open-source licence for your checks, Bruin's CLI, GX Core, and dbt are Apache 2.0.

Is Great Expectations still maintained?

Yes: GX Core continues as an open-source, Apache 2.0 project with Fivetran as its steward since 2026, while GX Cloud was sold to FICO and stopped being publicly available on 1 June 2026. If you wanted a managed product, Soda Cloud, Monte Carlo, and Bruin Cloud (which schedules Bruin's checks and alerts on failures) are the options in this guide.

We build Bruin, so we are not neutral, but we have tried to be straight about where each tool wins. If we got something wrong, tell us and we will update the piece. To see the pipeline-native approach, read about Bruin quality checks, check pricing, or browse Bruin on GitHub. For more on the basics, see what a data quality check is, what a SQL unit test is, and, for the transformation layer these checks sit in, the best data transformation tools.