Skip to main content
dbt Core™ 1.11 introduces user-defined functions (UDFs) as first-class resources and turns on JSON-schema deprecation warnings by default for the major adapters, making project cleanup visible without any opt-in. This guide is based on the official dbt™ upgrade guide for v1.11; check the dbt Core™ 1.11 changelog for the full detail.
Prerequisites
  • An Admin role in Paradime, needed to change the workspace dbt™ version.
  • Your project on dbt™ 1.10 with deprecation warnings largely cleaned up via the 1.10 guide.
Estimated time: 30 minutes, plus project testing.

​
What can break

Upgrading remains backward compatible within 1.x, with behavior changes gated behind flags. The visible change is noise: on the Snowflake, Databricks, BigQuery, and Redshift adapters, deprecation warnings from JSON-schema validation of your YAML files are now on by default. If your Bolt schedules promote warnings to errors, review the section below before switching. Also check for scripts and environment variables using engine configuration variables: the DBT_ENGINE_ prefix now applies, for example DBT_STATE becomes DBT_ENGINE_STATE and DBT_PROJECT_DIR becomes DBT_ENGINE_PROJECT_DIR. See About flags (global configs) for the full mapping.

​
What’s new in dbt™ 1.11

​
User-defined functions (UDFs)

UDFs let you define and register custom functions in your warehouse as first-class dbt™ resources. Like macros they promote code reuse, but because they are warehouse objects the same logic is reusable in tools outside dbt™:
  • Define UDFs in a functions/ directory with corresponding YAML configuration.
  • Create, update, and rename them as part of DAG execution with dbt build --select "resource_type:function".
  • During dbt build, UDFs are built before the models that reference them.
  • Reference a UDF in models with the {{ function('function_name') }} Jinja macro.
  • With --defer and --state, function() calls resolve to the UDF in the state manifest, so dependent models can run without rebuilding the UDF.
See the UDF documentation for prerequisites and definitions.

​
Deprecation warnings enabled by default

For projects on the Snowflake, Databricks, BigQuery, and Redshift adapters, JSON-schema validation of YAML configuration files (such as schema.yml and dbt_project.yml) now raises deprecation warnings by default, surfacing misspelled config keys, deprecated properties, and incorrect data types. The warnings you’ll see by default:
  • CustomKeyInConfigDeprecation
  • CustomKeyInObjectDeprecation
  • CustomTopLevelKeyDeprecation
  • MissingPlusPrefixDeprecation
  • SourceOverrideDeprecation
Each can be silenced individually via warn_error_options in dbt_project.yml, or all deprecations at once:
The same is available on the command line, for example dbt parse --warn-error-options '{"silence": ["Deprecations"]}'.

​
New behavior flags

Both introduced in 1.11 and disabled by default; opt in under flags: in dbt_project.yml:

​
Adapter-specific changes

  • Snowflake: basic table materialization on Iceberg tables registered in a Glue catalog through a catalog-linked database; cluster_by and immutable_where supported on dynamic tables; copy_grants: true preserves object-level privileges when a dynamic table is recreated on --full-refresh; refresh_warehouse picks a separate warehouse for a dynamic table’s automatic refreshes (with snowflake_warehouse still used for DDL).
  • BigQuery: set bigquery_use_batch_source_freshness to true to calculate metadata-based source freshness in a single batch query instead of one query per source.
  • Redshift: the datasharing profile credential (beta) uses Redshift-native SHOW commands instead of PostgreSQL catalog tables, enabling cross-database and cross-cluster access with Redshift Datasharing; drop_without_cascade: true emits DROP statements without CASCADE to skip dependency-graph resolution overhead (errors if a dependent object exists).
  • Spark: new PyHive retry-handling profile configurations: poll_interval, query_timeout (raises DbtRuntimeError on overrun), and query_retries.

​
Quick hits

  • The --sqlparse flag sets sqlparse MAX_GROUPING_DEPTH and MAX_GROUPING_TOKENS for SQL parsing during compilation.
  • dbt ls can write out nested keys, for example dbt ls --output json --output-keys config.materialized.
  • Manifest metadata now includes run_started_at.
  • Disabling a model automatically disables its unit tests.
  • config.meta_get() and config.meta_require() access custom configurations under meta (also backported to 1.10).

​
Upgrade steps

1

Test on 1.11 in a non-production environment

Pin a Bolt environment to dbt™ 1.11 in Settings > Environments or use a staging workspace, then run dbt parse in the Code IDE terminal and review the newly visible deprecation warnings.
2

Fix or silence the new warnings

Fix genuine issues (misspelled keys, deprecated properties, missing + prefixes), and silence any warning types you’re deferring via warn_error_options so Bolt logs stay readable.
3

Update environment variables and scripts

Rename engine configuration variables to the DBT_ENGINE_ prefix where you use them, for example in environment variables or schedule commands.
4

Switch the workspace version

In Settings > Workspace > General, select Change version, choose 1.11, and save. See Upgrade dbt Core™ version.
dbt --version reports 1.11.x, Bolt schedules run green, and parse output contains only warnings you’ve deliberately deferred. The most likely failure is a schedule with --warn-error promoting the newly-default deprecation warnings to errors.

​
Next steps

Upgrade to dbt™ 1.12

The v2 parser preview and a large batch of behavior flags flipping on by default.

Upgrade with the DinoAI agent

Automate the warning cleanup with an agent-driven PR.

Manage dbt™ version

The workspace setting and per-environment overrides.

Official v1.11 upgrade guide

The upstream dbt™ documentation this guide is based on.

Related topics

Upgrade to dbt™ 1.10dbt™ version upgradesUpgrade to dbt™ 1.12Upgrade with the DinoAI agentPrepare for dbt™ v2