dbt Fusion fixes Databricks incremental runs with custom primary-key constraints
Incremental models on Databricks with custom PK constraints were previously silently broken or erroring, which is a common pattern for merge-based incremental strategies relying on constraint metadata for change detection — this fix removes a real blocker for teams using constraint-driven incremental logic. The state:modified fixes also matter for CI/CD job selection: false positives from environment-conditional Jinja configs were causing unnecessary rebuilds of snapshots and seeds across environments, inflating warehouse compute costs in slim-CI setups.
What changed
dbt-fusion 2.0.0-alpha.4 fixes a SQL error that occurred on Databricks incremental runs when models used custom primary-key constraints, by correctly exposing constraint attributes (type, name, render) to Jinja templates and normalizing custom PK expressions so incremental diffs are stable. The release also expanded state:modified logic in dbt-core so environment-aware Jinja in meta/tags/target_schema/target_database/alias/dbt_valid_to_current configs no longer causes false-positive "modified" flags on seeds, snapshots, and data tests.
Why it matters
Incremental models on Databricks with custom PK constraints were previously silently broken or erroring, which is a common pattern for merge-based incremental strategies relying on constraint metadata for change detection — this fix removes a real blocker for teams using constraint-driven incremental logic. The state:modified fixes also matter for CI/CD job selection: false positives from environment-conditional Jinja configs were causing unnecessary rebuilds of snapshots and seeds across environments, inflating warehouse compute costs in slim-CI setups.