Soda is a data quality platform built on Soda Core, a Python library and CLI that runs checks and data contracts inside pipelines, with Soda Cloud for triage and collaboration and a hosted or self-hosted Runner for scheduled observability.
Soda Core runs as a Python library or CLI wherever the pipeline runs, including against Pandas, Polars, and Spark dataframes; checks execute against sixteen sources without extracting data. Soda Cloud is the triage workspace, and the Runner, hosted by Soda or self-hosted in Kubernetes, executes scheduled observability.
How Soda answers the questions Data Quality turns on.
| How it works | |
| Authoring model | YAML contracts in a language of their own, a dataset named by fully-qualified name, with checks at dataset level and inside a columns list. Explicitly not SodaCL, which is the v3 language and which v4 contracts do not use; Soda Cloud adds a no-code contract builder on the paid tier |
| Detection model | Declared expectations first (a contract states what must hold and verification says whether it does) with metric monitoring alongside, learning trends and seasonality to flag anomalies in freshness, row counts and nulls that nobody wrote a threshold for |
| Built-in monitors | Eleven check types in the contract language, schema, row count, freshness, missing, invalid, duplicate, aggregate, metric over custom SQL, failed rows, reconciliation between a source and a target, and group-by variants |
| Prevention or detection | Both, and which one depends on where it runs, a contract verified inside a pipeline step fails that step, stopping bad data before it lands, while the same contract watched by a Runner on a schedule reports after the fact. One artefact serves prevention and detection |
| Lineage | None of its own, and Soda says so, lineage comes from partner tools, which Soda consumes to organise rules and alerts and to flag poor-quality data inside someone else's lineage diagram |
| Alerts and delivery | Notification rules routed by ownership by default, so a failing or warning check reaches whoever owns the check and whoever owns the dataset, with Slack, Jira, ServiceNow through webhooks, and plain webhooks for the rest |
| Incidents and ownership | The strongest answer this row gives, a failing check opens an incident in Soda Cloud, Slack gets an auto-generated channel for the investigation, and Jira tickets are created and kept in sync on status, description and links |
| Running it | |
| What you run | Soda Core as a Python library and CLI wherever the pipeline already runs, including against in-memory Pandas, Polars and Spark dataframes; or a Runner, hosted by Soda or self-hosted in Kubernetes, for scheduled observability. Checks execute against the source rather than extracting the data |
| Connections | |
| Connectors | Sixteen data sources (Athena, BigQuery, Databricks SQL, Dremio, DuckDB, Fabric, Oracle, Pandas, Polars, PostgreSQL, Redshift, Snowflake, Spark dataframes, SQL Server, Synapse and Trino) but tiered, with contracts running on ten of them and metric monitoring on eight, so the list narrows as you move from testing to observability |
| Cost | |
| Billing unit | Soda Processing Units, pay-as-you-go past a free allowance, and unusually, a published price beside the unit: Free at $0 with free SPUs and unlimited users, Team at $750 a month adding collaborative contracts, a no-code interface, RBAC, SSO and private deployment, and Enterprise on request |
vs Soda: Commercial · Subscription · Operational complexity: Medium
vs Soda: Commercial · Subscription · Operational complexity: Medium
vs Soda: Open source (permissive) · Self-hosted · Free · Scala