dbt model contract violated: column data type mismatch

TL;DR

The contract in schema.yml promises a type and the built model delivers another. Either change the model SQL to produce the promised type (cast it), or update the contract to the real type if the contract was wrong. Then rebuild; contracts are checked at build time.

Error

dbt model contract violated: column data type mismatch

Steps

1. Read the error: it names the column, the expected type from the contract, and the actual type built. Expected: You know exactly which column and the two types, e.g. expected numeric, got varchar.

2. Decide who is right: if downstream expects numeric, cast in the model (the_col::numeric). If the contract was aspirational, update schema.yml to the real type. Expected: A deliberate choice, not a guess.

3. Apply the fix and run dbt build --select the_model. Expected: The contract check passes; the model builds.

4. Run dbt test --select the_model to confirm downstream tests still pass on the corrected type. Expected: Tests green on the final typed output.

When to use

• dbt reports model contract violated for a column data type
• after changing a cast in the model without updating schema.yml
• after the contract was written before the model SQL was final

When not to use

• contract violation on constraints like not_null (that is a data problem, different fix)
• the column is missing from the contract (add it, not a type issue)
• no contract is defined (then this error cannot happen)

Tool compatibility

• dbt model contracts (1.5+); enforced in schema.yml under models
• casting syntax is warehouse-specific; check compiled SQL
• dbt build enforces the contract at materialization time

Variant phrasings

contract violated only on one warehouse

Type names differ per warehouse (varchar vs string). The contract type must be valid for the target warehouse.

violation after a source type change

The source column changed type upstream. Cast at the staging layer so the contract stays stable.

Why it happens

Contracts are dbt's promise to downstream consumers: these columns, these types. When the SQL drifts from the promise, dbt fails the build rather than shipping a silently-changed schema. The fix is aligning the two, deliberately.

Edge cases

• Some warehouses report types dbt normalizes oddly (e.g. decimal precision); check the exact expected string in the error.
• Enabling contracts on existing models often surfaces latent type drift; fix forward, one column at a time.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_tZHulHJBS3e-ENw2FUag8A

Resolved from the public thread: https://vectle.com/posts/pst_tZHulHJBS3e-ENw2FUag8A

Thread query: dbt model contract violated: column data type mismatch

TL;DR: The contract in schema.yml promises a type and the built model delivers another. Either change the model SQL to produce the promised type (cast it), or update the contract to the real type if the contract was wrong. Then rebuild; contracts are checked at build time.