dbt-core v1.12.2 - Databricks Config Schema Validation

dbt-core tag v1.12.2 was published on August 12, 2026. The change operators will see first is JSON schema validation for Databricks adapter config keys. query_tags, zorder, options, unique_tmp_table_suffix, and skip_optimize no longer raise spurious CustomKeyInConfigDeprecation warnings.

The full release notes and downloads are on the GitHub release page. This is a stable tag, not a beta or a release candidate.

Databricks ELT projects often set adapter config on models. Those keys are real for the dbt-databricks adapter. Core schema validation did not list them, so a valid config still produced CustomKeyInConfigDeprecation. The warning shows up in parse output and in CI logs. After a few noisy runs, people start ignoring every deprecation line, including ones that are real.

v1.12.2 adds five keys to the schema used for validation:

  • query_tags
  • zorder
  • options
  • unique_tmp_table_suffix
  • skip_optimize

The notes cite dbt-databricks issues 1540 and 1302. Those adapter issue numbers appear in the GitHub text without full URLs, so they stay as adapter side references, not as core links you can open from this page.

This is not a new warehouse feature. The notes do not redefine what those keys do in Databricks. Core is only changing whether they count as unknown custom config. The SQL the adapter emits is not described and should not be assumed to have changed.

The useful blast radius is CI. If a wrapper treats deprecation warnings as failures, this patch removes false hits for those five keys. If the project does not use the Databricks adapter, the delta is empty. Other adapters do not gain a blanket exception.

Parse time is the surface. Schema validation runs when config is checked, not when a warehouse statement executes. A model that already compiled will keep compiling. What should drop is the deprecation line for the keys above.

The list is closed. Any other adapter key that is still missing from the schema can still raise CustomKeyInConfigDeprecation. This tag does not claim a policy of accepting every adapter key in the ecosystem. If a key you rely on is not one of the five, expect the old warning until a later schema update names it.

Issue 15964 adds a warning when the installed dbt-core version is deprecated. That is the second user facing item in v1.12.2.

The notes do not name the log event, the version cutoff, or a flag to silence the line. Do not invent a CLI switch. Treat it as a warning that will show up in job logs once the installed version sits on the deprecation list that the project maintains.

For a platform team this is a fleet signal. Jobs that pin an old 1.x line will start saying so in logs. That helps when 1.10, 1.11, and 1.12 installs share the same runners. It is extra noise when a pin is frozen on purpose because an adapter or a warehouse contract has not moved.

The notes do not describe a hard fail. There is no migration procedure and no breaking change list. If a job starts exiting non zero after this tag, inspect the wrapper that promotes warnings to errors. That failure mode is local policy, not a documented core break.

Confirm the warning on a 1.12 install before you turn it into a fleet rule. Other 1.x tags have shipped similar messaging. This post covers v1.12.2 only. The cutoff that fires the warning is not printed in the release text, so measure it on a canary job rather than guessing from the issue title.

The last notes item is internal work. Core syncs JSON schemas from dbt-fusion. That is a catalog refresh, not a new command, not a new selection syntax, and not a documented runtime mode switch.

The Databricks key fix likely depends on that catalog being current. If schema files in the core tree lag the adapter, validation warns on keys the adapter already implements. Syncing from dbt-fusion is how those files get refreshed in this tag. The notes do not list file paths, so do not assume a specific schema filename on disk.

Operators should not expect a behavior change beyond validation. Manifest shape, node IDs, and run result JSON are not mentioned. Grep the notes for a new flag and you will not find one.

Treat the sync as packaging. After you install v1.12.2, the JSON schema artifacts that ship with core should match whatever dbt-fusion supplied at tag time. There is no migration. There is also no promise that every adapter key is now listed. If schema validation still flags a key you believe is official, report the key name against the adapter and against core. This tag only names the five Databricks keys above.

Winners are Databricks projects that were getting CustomKeyInConfigDeprecation on legal config, plus anyone who wants a log line when a pin is past deprecation. Losers are teams that wanted every adapter key accepted, or teams whose frozen pins will now print a warning they already knew about. Neither side gets a new CLI.