Soda

Soda is a data quality platform for data engineering and governance teams, with YAML data contracts checked in CI, anomaly monitors and a self-hosted option.

Soda catches bad data where it is produced, running quality checks against warehouse tables and pipeline outputs before reports and applications read them. Soda Data Inc., an independent company with offices in Chicago and Brussels, builds and sells it. The platform puts data testing and data observability in one account, so a failed check and an unusual metric land in the same place. At its centre is the data contract, an agreement between the team that produces a dataset and the teams that depend on it. Contracts are written in YAML and stored in Git beside the data models, or authored in Soda Cloud through a no-code editor with a Copilot panel. The Soda CLI verifies a contract on every commit, pull request or deployment and stops the pipeline when a check fails. Metric monitors learn the normal pattern of row counts and other metrics and flag anomalies, while profiling records types, distinct counts, null counts and summary statistics for each column. Data Standards let a team write a set of checks once and deploy it across many datasets. Failed checks become issues with an owner and a status, and Agentic Data Cleansing proposes fixes that a data steward approves or rejects. Soda suits data engineering teams that want quality rules versioned in Git and enforced in CI. It also fits governance teams where business users and stewards co-author rules with engineers, and data mesh setups where each domain owns contracts for its datasets. Organisations that must keep data inside their own cloud can run the self-hosted Soda Runner in their Kubernetes environment, and the Diagnostics Warehouse stores failed records in their own warehouse. Engineers who prefer code can start from Soda Core, the Python library behind the checks, released under the Elastic License 2.0. Common jobs include blocking a broken table from reaching production, reconciling data during a cloud migration and supporting BCBS 239 governance. Checks run on Snowflake, BigQuery, Databricks, Postgres and other sources, and on Pandas, Polars or Spark DataFrames through the Python libraries. Airflow and Dagster call the checks as a step in a pipeline, while notification rules post failures to Slack or Microsoft Teams and open tickets in Jira or ServiceNow. Results also reach Collibra, Alation or Atlan, so anyone browsing the catalog can tell whether a dataset passed its checks before relying on it.