Data quality failures are expensive and silent. A broken pipeline does not crash — it produces wrong data that flows into dashboards, models, and decisions. The error is discovered weeks later when a business metric looks wrong, and by then the damage is done. Data quality platforms exist to catch these failures early, before wrong data reaches consumers.

Three tools represent the main approaches to data quality: Great Expectations (assertion-based testing), Soda (checks-as-code), and Monte Carlo (automated anomaly detection). They are not competitors in the traditional sense — they address different maturity levels and different types of data quality problems.

The Three Approaches

Data quality tools fall into three categories based on how they detect problems:

1. Assertion-based: You define explicit rules (“this column must not be null,” “this value must be positive,” “this table must have at least 1000 rows”) and the tool checks them. Great Expectations is the primary example.
2. Checks-based: You define quality checks in a declarative language (SQL or YAML) that is easier to write and maintain than code. Soda is the primary example.
3. Anomaly-based: The tool learns the normal behavior of your data and alerts you when something deviates. Monte Carlo is the primary example.

Each approach catches different types of problems. Assertions catch known risks. Checks catch known risks with less friction. Anomaly detection catches unknown risks — the problems you did not think to write a rule for.

Most production data quality strategies combine approaches: assertions for critical business rules, anomaly detection for broad monitoring, and checks as the bridge between the two.

Great Expectations: The Assertion Engine

Great Expectations (GX) was the first widely adopted open source data quality tool. It introduced the concept of “expectations” — assertions about your data that can be validated programmatically. “Expect column values to not be null.” “Expect column values to be between 0 and 100.” “Expect the number of rows to be between 900 and 1100.”

The expectation library is extensive — over 50 built-in expectations covering null checks, type checks, range checks, uniqueness, referential integrity, distribution checks, and more. Custom expectations can be defined for domain-specific rules. The coverage of common data quality patterns is the broadest of the three tools.

GX’s “Data Docs” feature generates HTML reports from validation results. These reports are useful for auditing and for sharing quality status with stakeholders who do not run the tool directly. The reports show which expectations passed, which failed, and the specific values that caused failures.

The operational model requires integration with your pipeline. You call GX from your Airflow DAG, dbt post-hook, or custom Python script. GX runs the expectations against your data and returns pass/fail results. The integration is flexible but requires developer effort — someone must write the expectation suites, wire them into the pipeline, and handle the results.

GX’s limitation is maintenance burden. As your data evolves, expectations must be updated. A new column requires new expectations. A schema change may break existing expectations. A business rule change requires editing expectation suites. The maintenance cost grows with the number of tables and the rate of schema evolution.

GX’s open source model (GX 0.18+ with the newer architecture) requires you to manage the validation store, the data context, and the checkpoint configuration. The operational surface is smaller than a full application but is non-trivial for teams new to the tool.

Soda: Checks as Code

Soda takes the assertion concept and simplifies it. Instead of writing Python expectations, you write checks in SodaCL — a YAML-based language designed for data quality. The syntax is intentionally simple: missing_count(email) = 0, row_count > 1000, avg(revenue) between 100 and 500.

The simpler syntax lowers the barrier for data analysts who are comfortable with SQL but not Python. A data analyst can write and maintain Soda checks without developer support, which distributes the data quality effort across the team instead of concentrating it in engineering.

Soda’s SQL-based execution means checks run directly in your data warehouse. No external compute, no data movement, no separate infrastructure. The warehouse does the work, and Soda orchestrates and reports the results. For teams that want data quality without adding infrastructure, this is a real advantage.

Soda’s “anomaly detection” capability (in Soda Cloud) adds automated checks on top of the declarative checks. Soda learns the normal behavior of your data (row counts, column distributions, freshness) and alerts you when something changes. This bridges the gap between assertion-based and anomaly-based approaches.

The limitation is that Soda’s anomaly detection is less sophisticated than Monte Carlo’s. The baselines are simpler, the alerting is less nuanced, and the root cause analysis is thinner. Soda provides the anomaly signal; Monte Carlo provides the investigation workflow.

Soda Cloud (the managed product) provides a dashboard, alerting, and collaboration features. The open source Soda Core provides the checking engine without the collaboration layer. The split means small teams can start with Soda Cloud at low cost, and larger teams can use the managed platform for coordination.

Monte Carlo: Automated Monitoring

Monte Carlo takes the most automated approach. Instead of requiring you to define rules or checks, Monte Carlo monitors your data warehouse and learns what normal looks like. When a table stops updating, when row counts shift unexpectedly, when a column’s distribution changes, Monte Carlo alerts you.

The automated approach catches problems that assertion-based and checks-based tools miss — because you did not think to write a check for them. The most common data quality failures are not the ones you anticipated. They are the ones caused by unexpected interactions between pipeline components, upstream schema changes, or data source outages. Monte Carlo’s anomaly detection catches these because it does not rely on pre-defined rules.

Monte Carlo’s lineage integration is the strongest of the three. When an anomaly is detected, Monte Carlo traces it upstream to identify the root cause. The orders table has a freshness issue — the root cause is the Airflow DAG that loads orders from the API, which failed silently two hours ago. This root cause analysis saves hours of manual investigation.

The alerting is context-aware. Monte Carlo considers the severity of the anomaly, the criticality of the affected table, and the downstream consumers when deciding whether to alert and how urgently. A freshness issue on a table that feeds a CEO dashboard gets higher priority than a distribution shift on a table that feeds an internal report.

The limitation is cost. Monte Carlo is the most expensive of the three, with pricing based on the number of tables monitored. For large data warehouses with thousands of tables, the cost is significant. Monte Carlo is positioned as an enterprise tool with enterprise pricing.

The other limitation is the lack of assertion-based checks. Monte Carlo does not replace explicit business rules — “this column must always contain valid country codes” is a rule that anomaly detection cannot enforce. Monte Carlo catches statistical anomalies, not semantic violations. The most effective data quality strategy uses Monte Carlo for broad monitoring and assertions (via Great Expectations or Soda) for critical business rules.

Maturity Model

Decision Framework

Use Great Expectations when your team is Python-proficient, you want open source control, and you are building your first systematic data quality practice. Best for engineering teams that can invest in writing and maintaining expectation suites and want the broadest assertion library.

Use Soda when your team includes data analysts who write SQL, you want checks in your warehouse without external compute, and you prefer a simpler syntax than Python expectations. Best for teams that want to distribute data quality responsibility beyond engineering.

Use Monte Carlo when your data warehouse has grown to the point where writing checks for every table is impractical, you need automated anomaly detection, and your budget can absorb the enterprise pricing. Best for data platform teams that need broad monitoring coverage with minimal manual configuration.

Use Soda plus Monte Carlo when you want declarative checks for critical business rules (Soda) combined with automated anomaly detection for broad monitoring (Monte Carlo). This combination provides the most complete coverage: known risks are checked explicitly, unknown risks are detected automatically.

The most common mistake is choosing Monte Carlo before you have basic assertions in place. Anomaly detection supplements assertions — it does not replace them. Start with assertions for your most critical tables and rules, then add anomaly detection when the assertion maintenance burden becomes unsustainable.