dbt-core v1.12.2 - Databricks Config Schema

dbt-core v1.12.2 went out on 12 August 2026 as a small patch on the 1.12 line. The change that shows up in parse logs is jsonschema recognition of five Databricks adapter config keys that were raising spurious CustomKeyInConfigDeprecation warnings. The same tag also warns when the installed dbt version is deprecated, and it syncs JSON schemas from dbt-fusion.

The full release notes and downloads are on the GitHub release page.

dbt-core now treats five Databricks adapter config keys as known during jsonschema validation: query_tags, zorder, options, unique_tmp_table_suffix, and skip_optimize. The notes call the old warnings spurious. Those keys were valid adapter config. The schema file did not know their names, so validation listed them as custom.

That warning is easy to misread. Teams that grep parse output for deprecations would see Databricks incremental and optimize settings listed as if a model author had invented the keys. The release points at dbt-databricks#1540 and dbt-databricks#1302 as the source of the key list. Those ticket numbers appear in the notes without full URLs, so they stay adapter side references rather than links you can click from this page.

The five names map to ordinary Databricks ELT knobs. query_tags attaches warehouse attribution on statements. zorder is clustering after a table write. options is the extra table options map. unique_tmp_table_suffix controls the suffix on temp tables during incremental swaps. skip_optimize skips a later OPTIMIZE. None of that is new behavior claimed by this tag. The claim is narrower. jsonschema no longer flags those keys as custom, so CustomKeyInConfigDeprecation should drop for them.

If you run Databricks models with any of those keys in config(), read parse logs after you move to v1.12.2. Confirm the warning is gone for the keys you actually set. Leave the rest of the deprecation list alone. A noisy deprecation channel is worse than a quiet one when CI treats any warning as a failed gate. False positives train people to ignore the list.

The Features section adds a warning when the running dbt version is itself deprecated. The tracker is issue 15964. The notes do not quote the message text, do not name the cutoff version, and do not say whether the warning is fatal.

Keep that path separate from the Databricks config fix. One path complains about the dbt package you installed. The other path was complaining about keys on models. They share a deprecation shaped log line and nothing else. Mixing them will waste a lot of time in a support channel.

If images or lockfiles still pin an old dbt-core line, expect extra log lines after you take v1.12.2. If you already run a current 1.12 pin, this feature may never fire. The notes do not say which versions count as deprecated, so the only way to know is to run a parse on the pin you actually ship. Treat a new warning here as a signal to plan an upgrade of the package, not as a model config bug.

The notes also record a sync of JSON schemas from dbt-fusion. That line sits in the internal section. No migration step is attached. No list of schema file paths is attached. The notes do not claim any change to compiled SQL.

The Databricks key fix and this sync both touch JSON schemas. The notes still list them as two items. Do not assume one is only a side effect of the other. If you vendor the schema artifacts that ship with dbt-core, diff them against the previous 1.12 tag after upgrade. That is the useful check for this item. Most ELT jobs will not see the sync except through the Databricks warning going away.

This is maintenance. It is the kind of patch note that looks empty until a later tag explains a schema field you actually use. Until then, do not budget runtime testing for it beyond a parse of Databricks models that set the five keys above.

• GitHub release page
• dbt-core repository
• Tag v1.12.2