Soda

Overview

Soda is a data quality and data contract verification engine, and its defining choice is YAML. You declare what the data should look like in a contract file and Soda validates both schema and data against it.

That is the sharpest contrast in this category: Great Expectations is Python, Deequ is a Scala DSL, Pandera is Python typing, and Soda is a declarative document a non-engineer can read.

Check the licence before adopting it, because it changed. Soda Core moved from Apache 2.0 to the Elastic License 2.0 with version 4 in January 2026, which is source-available rather than open source: you may use, fork and run it, but not offer it as a hosted service or circumvent its licence key.

Contracts are dataset-scoped with a columns block, support variables for parameterisation and a dataset-level filter, and can be bootstrapped straight from an existing schema rather than written from scratch.

The check vocabulary is unusually complete for a declarative tool: schema, row count, freshness, missing, invalid, duplicate, aggregate, metric, failed rows, reconciliation and group by.

Freshness is first-class, measuring time between now and the newest timestamp, which neither Great Expectations nor Pandera publishes. Reconciliation covers source-to-target comparison.

Its failure behaviour is the best documented of the four, with distinct exit codes for passed, failed, warning only, could not run, and could not reach the cloud, which makes it genuinely CI-shaped.

Contracts are versioned artefacts: publish makes one authoritative in Soda Cloud, fetch pulls it back, and both Git- managed and Cloud-managed contracts are supported.

Record-level anomaly detection promises coverage with no configuration, but read the status: it is marked coming soon for enterprise users and gated behind a sales conversation.

The 2026 direction is contracts plus agents, with a contract autopilot, a documented MCP server and a Claude Code plugin marketplace.

Key features and capabilities

The same headings are used for every testing & validation entry, so two tools can be read side by side.

How checks are written

• Declarative YAML contracts, dataset-scoped, with a columns block for per-column checks
• Contracts can be bootstrapped from an existing dataset's schema rather than written from scratch
• Variables give parameterisation, and a dataset-level filter applies to every check
• Contracts are versioned artefacts, published to and fetched from Soda Cloud
• A no-code authoring interface and a templates gallery exist on the paid tier

What it can check

• Eleven published check types, from schema and row count through missing, invalid and duplicate
• Freshness is first-class, measuring the gap between now and the newest timestamp
• Custom SQL through metric checks and failed-row checks taking an expression or an opaque query
• Reconciliation covers source-to-target differences in rows, aggregates, duplicates, freshness and schema
• Anomaly detection is not part of the contract language; it is a separate observability feature

Where checks run

• Checks run locally in your own environment or remotely through a Soda runner
• Checks are pushed to the data source as SQL, with 2026 work dominated by dialect coverage
• Published sources include Databricks, Snowflake, BigQuery, Redshift, Postgres, MySQL, Spark, DuckDB and Trino
• In-memory sources such as Spark and DataFrames work in Soda Core but not on the hosted runner
• A CLI covers cloud setup, data sources, and contract create, test, publish, fetch and verify

Results and alerting

• Results publish to Soda Cloud as the shared workspace for triage and incident resolution
• Alerting and ticketing through Slack, Teams, Jira, PagerDuty, ServiceNow, Opsgenie, webhooks and GitHub
• Distinct exit codes for passed, failed, warnings only, could not run, and could not reach the cloud
• Failed-row checks surface the offending rows, needing a diagnostics warehouse for stored samples
• Customisable dashboards shipped in August 2026

Scale and performance

• Filters at two levels, a dataset filter for all checks and a per-check filter on top
• Partition-aware pushdown is actively developed, including BigQuery partition filters
• Record-level anomaly detection promises no-configuration coverage across columns, rows and segments
• That feature is marked coming soon for enterprise users and gated behind sales contact
• Metric anomaly detection is published more broadly, across freshness, row counts and nulls

Integrations

• Orchestration through Airflow, Dagster, Prefect and Azure Data Factory
• Catalogues including Atlan, Alation, Collibra, data.world, Zeenea and Purview
• A REST API in EU and US regions, a Python API, webhooks and a documented MCP server
• The GitHub Action repository is archived, superseded by the version 4 CLI and its exit codes
• No first-party dbt integration documentation exists for version 4, despite dbt demo repositories

Where it runs and what it costs

• Soda Core as a library and CLI, giving full control of orchestration but no observability
• A Soda-hosted runner adding observability and scheduling, unable to scan in-memory sources
• A self-hosted runner with the same capabilities, needing Kubernetes expertise
• Two published regions, the European Union and the United States
• Billed in Soda processing units, accumulating daily and queryable through the API

Pricing

SubscriptionFree tier; Team at $750 a month

Three tiers. Free is $0 a month with a free allowance of Soda processing units, pipeline testing, metrics observability and alerting integrations, no card required, or a cloud evaluation account covering three datasets. Team is $750 a month, adding unlimited users, pay-as-you-go units, catalogue integrations, collaborative contracts, a no-code interface, audit logs, private deployment and single sign-on. Enterprise is quote-only. Not published: how many units are free, what a scan consumes, the price of an extra unit, or any trial length.

Vendor pricing page →

Demos and videos

• Writing data contracts on autopilot Product demo · YouTube
• How to create a data contract Tutorial · YouTube

About Soda

Soda was co-founded by Maarten Masschelein, its chief executive, and Tom Baeyens, its chief technology officer, and publishes two offices, Chicago and Brussels, without saying which is the legal headquarters; it publishes no founding year, team size or investor list on its company page. Funding, from its own indexed press summaries, was a €2.6m seed led by Point Nine Capital and a €11.5m Series A led by Singular, taking total financing past €14m, though both release pages now return errors so those figures are second-hand. No funding, acquisition or leadership news is published for 2025 or 2026. Contributors number fewer than fifty.

Chicago and Brussels · soda.io