Catalyst vs Soda: data quality tools compared

SodaCL and Soda Core against contracts in the Open Data Contract Standard — setup, connectors, anomaly detection, and when each is the wrong choice.

2026-09-10 · 10 min read

Use Soda if you want an open-source CLI that runs checks from a file in your own infrastructure, you need connectors Catalyst doesn't have yet, or you want ML-driven anomaly detection on metrics. Use Catalyst if you want a hosted product with nothing to install, rules authored in a browser by people who don't use a terminal, and contracts stored in ODCS — an open standard rather than a vendor's own check language. Both are declarative, both push checks down to SQL, and both are pleasant to read. The real difference is that Soda is a runner you operate and Catalyst is a service you connect.

What Soda is

Soda comes in two halves. Soda Core is an open-source Python CLI: you install it with pip, describe your data source in a configuration file, write checks in SodaCL — the Soda Checks Language, a YAML dialect — and run soda scan. It exits non-zero when a check fails, which makes it natural inside CI, Airflow or a dbt job.

Soda Cloud is the commercial SaaS on top: dashboards, check history, incident workflow, alerting into Slack and ticketing systems, and anomaly detection that learns a metric's normal shape instead of comparing it to a threshold you had to guess. For organisations that cannot let a SaaS reach the warehouse directly, Soda offers a self-hosted agent that runs inside your own network and talks outward to Soda Cloud, so scans can still be configured centrally.

Soda's connector list is broad — the common warehouses plus Snowflake, Databricks, Athena, Trino, Oracle and others at the time of writing — and SodaCL is one of the more readable check languages in this category. Credit where it is due: it is the closest thing to a contract-style authoring experience outside of contracts themselves.

What Catalyst is

Catalyst is a hosted data quality product with no CLI and no library. You connect a read-only database user, it imports the schema, and you build rules in the browser: not-null, uniqueness, ranges, patterns, allowed sets, freshness, referential integrity, and custom SQL for the rest. Rules are stored as Open Data Contract Standard contracts — the visual builder and the YAML are two views of one document, and the YAML is the source of truth, so a change made in the UI is a one-line diff.

Checks run as SQL inside your warehouse on a schedule. The dataset stays there; Catalyst stores results, violation counts and up to five example failing rows per check, captured as the check runs, never the dataset itself. Connectors at the time of writing: PostgreSQL, MySQL, SQL Server, BigQuery, Redshift, Microsoft Fabric, plus CSV, JSON and Excel upload.

Head to head

Setup: what the first hour looks like

Soda Core's first hour is a small engineering task: create a Python environment, install the package for your warehouse, write a configuration.yml with credentials, write a checks.yml, run the scan, then decide what runs it on a schedule and where the results go. Nothing is difficult and the documentation is good. It is still a component you now own — a Python environment to patch, credentials to place somewhere safe, and a scheduler to wire up.

Soda Cloud removes some of that, but if your security posture requires the self-hosted agent, you have swapped a pip install for a Kubernetes deployment. That is a sensible trade for a large organisation with a platform team, and a poor one for a five-person data team.

Catalyst's first hour is configuration: create a read-only role, paste connection details, pick a table. The schema import reads the catalog and proposes a baseline contract from the types and nullability it finds, so you start by editing thirty generated rules rather than typing them. The PostgreSQL guide has the exact grants; Redshift has its own quirks worth reading first.

Authoring rules

SodaCL is genuinely nice to read:

checks for orders:
  - missing_count(order_id) = 0
  - duplicate_count(order_id) = 0
  - invalid_count(status) = 0:
      valid values: [pending, paid, shipped, refunded]
  - freshness(created_at) < 24h
  - row_count > 0

The equivalent ODCS contract is more verbose, and the verbosity buys something:

apiVersion: v3.0.0
kind: DataContract
info:
  title: orders
  version: 1.0.0
  owner: data-platform
schema:
  - name: orders
    physicalType: table
    properties:
      - name: order_id
        logicalType: string
        required: true
        primaryKey: true
        quality:
          - rule: nullCount
            dimension: completeness
            severity: error
            mustBe: "0"
      - name: status
        logicalType: string
        quality:
          - rule: validValues
            dimension: conformity
            severity: error
            mustBe: "['pending', 'paid', 'shipped', 'refunded']"
      - name: created_at
        logicalType: timestamp
        quality:
          - rule: freshness
            dimension: timeliness
            severity: error
            mustBe: "<= 24h"

Three differences matter. The contract carries the schema as well as the checks, so it describes the dataset rather than only asserting things about it. Every rule carries a dimension, so a hundred rules roll up into a coverage matrix — are we covered on timeliness, or only on completeness? — instead of a flat list. And the format is an open standard under the Linux Foundation's Bitol project, not one vendor's language, so the rules are portable to any runner that speaks it.

Against that: SodaCL is more compact, and for an engineer writing checks in a text editor, compactness is a real feature. If your rules will only ever be written by people comfortable in a repository, the extra structure in ODCS is overhead you may not want.

Anomaly detection, and being honest about a gap

Soda Cloud's anomaly detection watches a metric over time and flags departures from its learned pattern. Catalyst does not have this. Catalyst checks are deterministic rules with thresholds you set: a row count that must be above zero, a freshness window of 24 hours, a range of plausible values.

Which you want depends on the failure you are trying to catch. Deterministic rules catch violations of a stated promise, and they never fire because Tuesday was quiet. Anomaly detection catches the failures nobody thought to write a rule for — a 40% drop in row count that is technically above your > 0 threshold — and it costs you a period of tuning and some false positives while it learns. If unknown-unknowns on volume and distribution are your main worry, that is a genuine reason to choose Soda.

Choose Soda if…

• You want an open-source runner you control. Soda Core is Apache-licensed and free; the checks run entirely inside your infrastructure with no vendor in the path.
• You need a warehouse Catalyst doesn't support yet — Snowflake, Databricks, Athena, Trino and Oracle are the obvious ones.
• Validation must fail a pipeline. soda scan returns a non-zero exit code, which is exactly what a CI job or an Airflow task wants. Catalyst monitors on its own schedule; it does not block your build.
• You want anomaly detection, not only threshold rules.
• Policy forbids a SaaS reaching your warehouse. The self-hosted agent keeps the connection inside your network. Catalyst is EU-hosted and stores only results, violation counts and up to five example failing rows per check, but the connection is still inbound from a service.
• Your checks live next to your dbt project and you want them versioned, reviewed and run in the same job as the models they cover.
• Your team already knows SodaCL. Familiarity is worth more than a marginally better format.

Choose Catalyst if…

• The people who know the business rules don't use a terminal. An analyst or domain owner can add a rule without a pull request, a Python environment or a code review from the platform team.
• You want rules in an open standard. ODCS contracts export as a file and import into anything that speaks the spec. SodaCL is readable, but it is Soda's.
• You want the whole thing to be one product. Scheduling, history, coverage and drill-down arrive configured rather than assembled from a CLI plus a cloud account plus an agent plus an orchestrator.
• Governance is part of the requirement. RBAC, an audit log and SSO are in the product on day one.
• You want to see the failing rows. A failed check links straight to a sample of the offending records, which is usually the first thing anyone asks for.
• You want predictable, small pricing. Starter is free for one connection and one dataset (PostgreSQL and MySQL); Team is €29 per user per month.

Can they coexist?

Yes, and the split is clean. Soda in the pipeline, as a gate: fast assertions that stop a bad load before it lands, run by the same job that built the table. Catalyst above the pipeline, as the contract and monitoring layer: the durable promises about datasets your consumers depend on, versioned as ODCS, checked on a schedule regardless of which pipeline wrote them today, with the run history and coverage view that the people who need to trust the numbers want, rather than a job log.

Migrating SodaCL to ODCS is manual at the time of writing — there is no importer — but the common checks map almost one-to-one (missing_count to nullCount, duplicate_count to duplicateCount, invalid_count with valid values to validValues, freshness to freshness), and importing the schema first generates most of the contract before you translate anything. If you are still deciding what to check at all, start with the guide to validating data.

Frequently asked questions

Is Soda free?

Soda Core, the open-source CLI, is free under the Apache 2.0 licence and you can run it in production without paying anyone. Soda Cloud — the hosted dashboards, alerting, incident workflow and anomaly detection — is a commercial product with its own pricing; check Soda's site for current terms. Most of what people picture when they say "Soda" is the cloud half.

Does Catalyst require Python or a CLI?

No. Catalyst is a web application. You connect a read-only database user, rules are built in the browser or written as ODCS YAML in the editor, and runs are scheduled in the product. There is nothing to install, no environment to maintain and no scan command to schedule.

What is the difference between SodaCL and ODCS?

SodaCL is Soda's own check language: compact, readable, and understood by Soda's runners. ODCS is the Open Data Contract Standard, an open specification developed under the Linux Foundation's Bitol project that describes a dataset's schema, ownership, service levels and quality rules in one versioned YAML document, and can be executed by any compatible tool. The practical difference is portability — an ODCS contract survives a change of vendor.

Does Catalyst do anomaly detection?

Not at the time of writing. Catalyst runs deterministic rules against thresholds you define, records pass/warn/fail history, and shows trends over time. If you specifically need statistical monitoring that learns a metric's normal range, Soda Cloud has it and Catalyst does not.

Can I use Soda and Catalyst together?

Yes. A common arrangement is Soda Core as a build gate inside the pipeline and Catalyst as the contract and monitoring layer over the tables that land, so pipeline failures stop bad data early while contracts give consumers a versioned, reviewable promise with its own schedule and run history.