Bring data quality together. In Databricks and beyond.

Add Soda when your data quality requirements span Databricks, other data sources and the teams that use them. Soda brings business checks, data contracts, monitoring and diagnostics into a shared platform. Engineers can work in code while business users contribute requirements through the UI. You can keep Databricks as your data platform and use Soda to manage quality across your data sources.

Lakeflow expectations validate records as pipelines run. Delta NOT NULL and CHECK constraints enforce conditions when data is written; primary and foreign keys are informational. Unity Catalog quality monitoring detects changes in table health and profiles data. DQX is a separate Databricks Labs framework for Spark validation, with rules, quarantine, a browser UI and other quality features. These tools have different execution models, availability and support terms.

Soda lets teams author shared contracts through code, a no-code editor or AI. DQX Studio also offers browser-based rules, AI suggestions, approvals and ODCS contract import. Its current documentation labels Studio Experimental. Both provide ways to capture business requirements; the choice is how you want to manage those requirements across your teams and data sources.

Yes. DQX can train models on representative data to identify unusual records and explain which fields contributed to each result. This differs from native table monitoring for freshness and completeness. DQX documents batch training and streaming scoring; its models do not currently retrain automatically. Teams need to plan for reviewing results and retraining as normal data patterns change.

DQX is a Databricks Labs project provided without a formal Databricks support SLA. Its maintainers direct issues to GitHub, where they are reviewed as time permits. This applies to DQX, not to Databricks’ supported native products. Teams evaluating DQX should account for operating and upgrading the framework. Soda offers commercial product support, with premium support on its Enterprise plan.

Yes. Existing controls can continue running while you introduce Soda on selected datasets or requirements. Keeping native controls does not itself import their definitions or results into Soda; migration and integration requirements need a separate review. Existing business logic can be adapted into Soda contract checks, including custom SQL, with validation before older checks are retired.

Yes. Soda supports Databricks SQL alongside sources such as Snowflake, BigQuery, PostgreSQL and SQL Server. Teams can manage quality requirements across those systems in Soda rather than limiting their quality program to one platform. Connection methods and available features vary by source, so review the supported integration for each system you want to cover.

Yes. Soda supports metric and record-level reconciliation between source and target datasets. Keyed row comparisons can identify missing records and mismatched values before a migration is complete. Teams can then keep running quality checks against the target. Run reconciliation through Soda Runner or the reconciliation extension for Python workflows; confirm plan and source support when planning the migration.

Soda offers hosted and self-hosted Runners. With a self-hosted Runner, checks execute in your environment; a Diagnostics Warehouse keeps failed-row data in your warehouse for investigation. Soda Cloud receives metadata, check results and monitoring metrics. The exact data flow depends on your deployment, so choose the Runner and diagnostics configuration that meets your access and privacy requirements.