> ## Documentation Index
> Fetch the complete documentation index at: https://docs.paradime.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Upgrade to dbt™ 1.11
> Move your Paradime workspace to dbt Core™ 1.11: user-defined functions, the DBT_ENGINE_ variable prefix, and JSON-schema deprecation warnings by default.
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](https://docs.getdbt.com/docs/dbt-versions/core-upgrade/upgrading-to-v1.11); check the [dbt Core™ 1.11 changelog](https://github.com/dbt-labs/dbt-core/blob/1.11.latest/CHANGELOG.md) for the full detail.
**Prerequisites**
* An [Admin role](/products/settings/users/role-based-access-control) 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](/guides/migrations/dbt-version-upgrades/upgrade-to-dbt-1.10).
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)](https://docs.getdbt.com/reference/global-configs/about-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](https://docs.getdbt.com/docs/build/udfs) 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:
```yaml theme={"system"}
flags:
warn_error_options:
silence:
- Deprecations
```
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`:
| Flag | What it does when enabled |
| ----------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `require_unique_project_resource_names` | Raises a `DuplicateResourceNameError` when two unversioned resources in the same package share a name, instead of the default `DuplicateNameDistinctNodeTypesDeprecation` warning. |
| `require_ref_searches_node_package_before_root` | When resolving a `ref()` inside a package model, searches the package where the model is defined before the root project, instead of the root project first. |
### 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
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.
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.
Rename engine configuration variables to the `DBT_ENGINE_` prefix where you use them, for example in [environment variables](/guides/paradime-101/getting-started-with-your-paradime-workspace/managing-workspace-configurations) or schedule commands.
In **Settings > Workspace > General**, select **Change version**, choose **1.11**, and save. See [Upgrade dbt Core™ version](/guides/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
The v2 parser preview and a large batch of behavior flags flipping on by default.
Automate the warning cleanup with an agent-driven PR.
The workspace setting and per-environment overrides.
The upstream dbt™ documentation this guide is based on.
## Related topics
- [Upgrade to dbt™ 1.10](/guides/migrations/dbt-version-upgrades/upgrade-to-dbt-1.10.md)
- [dbt™ version upgrades](/guides/migrations/dbt-version-upgrades/index.md)
- [Upgrade to dbt™ 1.12](/guides/migrations/dbt-version-upgrades/upgrade-to-dbt-1.12.md)
- [Upgrade with the DinoAI agent](/guides/migrations/dbt-version-upgrades/upgrade-with-the-dinoai-agent.md)
- [Prepare for dbt™ v2](/guides/migrations/dbt-version-upgrades/prepare-for-dbt-v2.md)