Enforcing data integrity with YAML-defined constraints

dbt allows you to define data constraints (not null, primary key, foreign key, check, custom) directly in a model's YAML properties, which dbt then compiles into DDL statements enforced by the underlying data platform. This ensures data integrity guarantees are pushed down to the warehouse itself, not just validated in dbt tests, but support and enforcement behavior vary significantly by adapter.

1 · Learn the must-know

• 1Constraints are defined under the 'constraints' key at the model level (table-level constraints like primary_key, foreign_key, check) or under a column's 'constraints' key (column-level constraints like not_null, primary_key, foreign_key).
• 2Constraints require the model to have a defined 'contract' (enforced: true) in its config, since dbt needs guaranteed column names, data types, and order to generate valid DDL.
• 3Platform enforcement differs: warehouses like Snowflake and Redshift may accept but not actively enforce foreign_key or check constraints (informational only), while Postgres and Databricks (via Delta) more strictly enforce not_null and check constraints.
• 4For platforms that don't support ALTER-based constraint application post-load, dbt generates constraints inline as part of the CREATE TABLE statement, meaning the model build will fail at compile/run time if data violates a not_null or check constraint.
• 5Primary key and foreign key constraints often require the 'type: primary_key'/'type: foreign_key' syntax with a 'to' and 'field' reference for foreign keys, pointing to a ref() or source() relation.
• 6Combining constraints with contracts turns schema and integrity violations into build-time errors rather than downstream surprises, but this also means any upstream schema drift will break the run until the YAML is updated to match.

2 · Check your understanding