Soda.

What Soda actually is

Soda is two products presented as one: Soda Core, a CLI/Python scan engine that takes a SodaCL YAML file plus a warehouse connection and produces validation results, and Soda Cloud, a SaaS aggregation surface for those scans with anomaly detection, incident workflows, and Collaborative Data Contracts. The pair runs in CI, in orchestrators (Airflow, Dagster, ADF, Databricks Workflows), or against a self-hosted Kubernetes runner — important for EU-residency-constrained buyers.

The defining authoring artifact is SodaCL, a YAML DSL for checks: things like row_count > 1000, freshness with column ts < 1d, anomaly score for missing_count(email) < default, plus custom SQL via failed rows. It’s one of the cleaner DSLs in this space and version-controls well.

Where it fits against the alternatives

Against great-expectations, Soda is the YAML answer to GX’s Python answer. Both are code-first, both run in CI, both produce validation artifacts. The licensing split is sharp: GX is Apache-2.0; Soda Core is Elastic License 2.0 (source-available). For buyers who specifically want pure OSS, GX is the path. For buyers who want a more polished managed-Cloud experience and a real data-contract surface, Soda is the path.

Against monte-carlo, anomalo, and bigeye, Soda spans both paradigms — deterministic SodaCL checks for the things you know to test, plus Soda AI anomaly detection for the things you don’t. The ML-only tools have deeper anomaly detection; Soda has cleaner code-first authoring and a more developed contract story.

Against datafold, Soda is post-merge to Datafold’s pre-merge. Datafold checks what will change if you merge a PR; Soda checks what is true about a table once data is there. Different lifecycle stages, often run together in mature stacks.

On the licensing question

Soda Core’s Elastic License 2.0 is a real consideration. ELv2 is “source-available” — you can read it, modify it, and self-host it, but you can’t offer Soda as a competing hosted service. For most buyers this is a non-issue. For buyers with a strict OSS mandate (typically government, regulated finance, or organizations with codified Apache-2.0/MIT requirements), it disqualifies the product even though the source is on GitHub. The relicense itself was a 2024-era event that long-time community members continue to flag.

How to evaluate it

The right test is to author a real SodaCL file for one of your warehouse tables that has actual quality issues — late freshness on Mondays, occasional duplicate keys, a column that periodically drifts. Run it in your CI and against Soda Cloud. Look at: did the YAML feel maintainable, did Soda AI surface anything useful that the deterministic checks missed, and how does the SPU consumption project as you scale to your full table count?

For the data-contracts angle specifically, walk through Collaborative Data Contracts end-to-end with one engineer and one business user. The promise of the feature is that both audiences can work in it — the test is whether they actually do.