> ## 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.10
> Move your Paradime workspace to dbt Core™ 1.10: sample mode, the anchors: key, and the first wave of deprecation warnings to clean up on the road to v2.
dbt Core™ 1.10 adds sample mode for faster development builds and, more importantly, starts warning about project code that will become invalid in future versions. Cleaning up these deprecation warnings now is the bulk of the work of preparing for dbt™ v2. This guide is based on the official [dbt™ upgrade guide for v1.10](https://docs.getdbt.com/docs/dbt-versions/core-upgrade/upgrading-to-v1.10); check the [dbt Core™ 1.10 changelog](https://github.com/dbt-labs/dbt-core/blob/1.10.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.9, upgraded via the [1.9 guide](/guides/migrations/dbt-version-upgrades/upgrade-to-dbt-1.9).
Estimated time: 30 minutes, plus deprecation cleanup.
## What can break
Upgrading itself is backward compatible: the new deprecation warnings are warnings, not errors, and fixing them is not a prerequisite for using 1.10. Two setups need attention:
If you run with `--warn-error` (or `--warn-error-options '{"error": "all"}'`), the new deprecation warnings get promoted to errors and can fail Bolt runs that passed on 1.9. To keep deprecations as warnings while still promoting everything else, set `"warn": ["Deprecations"]` in `warn_error_options` (new in 1.10).
**Snowflake column size change (September 2026).** Snowflake [plans to increase](https://docs.snowflake.com/en/release-notes/bcr-bundles/un-bundled/bcr-2118) the default column size for string and binary types, and `dbt-snowflake` below 1.10.6 may fail to build incremental models that combine collated string columns with `on_schema_change='sync_all_columns'`. Run `dbt ls -s config.materialized:incremental,config.on_schema_change:sync_all_columns --resource-type model` to check exposure.
## What's new in dbt™ 1.10
### The `--sample` flag
The [`--sample` flag](https://docs.getdbt.com/docs/build/sample-flag), available on `dbt run` and `dbt build`, runs dbt™ in sample mode: refs and sources are filtered with time-based sampling so you can validate model outputs without building entire models. This cuts development build times and warehouse cost on large datasets.
### The `anchors:` key for standalone YAML anchors
dbt™ 1.10 warns on unexpected top-level keys in properties YAML files. The common legitimate case is standalone YAML anchor definitions; move those under the new top-level `anchors:` key:
```yaml theme={"system"}
anchors:
- &id_column_alias
name: id
description: This is a unique identifier.
data_type: int
data_tests:
- not_null
- unique
models:
- name: my_first_model
columns:
- *id_column_alias
- name: unrelated_column_a
description: This column is not repeated in other models
- name: my_second_model
columns:
- *id_column_alias
```
Only fragments defined outside the main YAML structure need to move. See the [anchors reference](https://docs.getdbt.com/reference/resource-properties/anchors).
### Parsing `catalogs.yml`
dbt™ can now parse a `catalogs.yml` file, the first step toward external catalog support for Iceberg tables with write integrations. You define a catalog with `write_integrations` (external volume, table format, catalog type) and point producer models at it with `catalog_name` in the model config. See [external catalog support](https://docs.getdbt.com/docs/build/iceberg/about-catalogs).
### New behavior flags
Both introduced in 1.10 and disabled by default; opt in under `flags:` in `dbt_project.yml`:
| Flag | What it does when enabled |
| -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `validate_macro_args` | Warns when argument names or types in macro YAML don't match the macro's Jinja definition or use unsupported types. With `--warn-error`, out-of-sync declarations can fail the run at parse time. |
| `require_all_warnings_handled_by_warn_error` | Routes all warnings through the `--warn-error` / `--warn-error-options` handler for consistent promoting and silencing. With `--warn-error`, previously ignored warnings can start failing builds, so enable it gradually, one project at a time. |
### Deprecation warnings
Starting in 1.10, dbt™ warns about code that will become invalid in future versions. Fixing these is not required to use 1.10, but it is required before moving to [v2](/guides/migrations/dbt-version-upgrades/prepare-for-dbt-v2). Many are auto-fixable with the [`dbt-autofix` tool](https://github.com/dbt-labs/dbt-autofix), or with the [DinoAI upgrade agent](/guides/migrations/dbt-version-upgrades/upgrade-with-the-dinoai-agent).
**Custom properties and configs must move under `meta`.** dbt™ previously ignored unrecognized properties (including misspellings like `desciption:`) silently. Going forward, `meta` is the only place for custom user-defined attributes; everything else becomes strongly typed and strictly validated:
```yaml theme={"system"}
models:
- name: my_model
description: A model in my project.
config:
meta:
dbt_is_awesome: true
columns:
- name: my_column
config:
meta:
some_key: some_value
```
**Duplicate keys in the same YAML file.** dbt™ previously used the last occurrence silently. Delete unused duplicates or split them into separate files.
**Unexpected Jinja blocks.** Orphaned blocks such as an `{% endmacro %}` with no matching `{% macro %}` were silently ignored; delete them.
**Properties moving entirely to configs.** `freshness`, `meta`, `tags`, `docs`, `group`, and `access` move under `config:`. For example, source `freshness`:
```yaml theme={"system"}
sources:
- name: ecom
schema: raw
description: E-commerce data for the Jaffle Shop
config:
freshness:
warn_after:
count: 24
period: hour
```
**The `--models` / `--model` / `-m` flag.** Renamed to `--select` / `-s` back in dbt™ 0.21; it now raises a warning in 1.10 and errors in the v2 engine. Update Bolt schedule commands and scripts that still use it.
**Custom output path for source freshness.** Overriding the `sources.json` path with `--output` / `-o` on `dbt source freshness` is deprecated; use `--target-path` to set the artifact path for the whole step.
**`warn_error_options` renames.** `include` and `exclude` are deprecated in favor of `error` and `warn`:
```yaml theme={"system"}
flags:
warn_error_options:
error: # Previously called "include"
warn: # Previously called "exclude"
silence: # To silence or ignore warnings
- NoNodesForSelectionCriteria
```
### Adapter-specific changes
* **Snowflake**: the `platform_detection_timeout_seconds` profile parameter controls how long the connector waits when detecting the cloud platform.
* **BigQuery**: jobs that exceed their configured timeout receive a cancellation request; if the request fails, the BigQuery job may keep running in the background until you cancel it manually.
### Quick hits
* The `--use-fast-test-edges` flag on `dbt build` reduces the number of test edges in the execution graph, which can significantly cut run times and memory usage in large projects.
* The `loaded_at_query` source property specifies custom SQL for the source freshness timestamp, as an alternative to `loaded_at_field` (you cannot set both).
* `config.meta_get()` and `config.meta_require()` access custom configurations stored under `meta`.
## Upgrade steps
Pin a Bolt environment to dbt™ 1.10 in **Settings > Environments**, or switch the version in a staging workspace, and run `dbt parse` in the Code IDE terminal to surface the new deprecation warnings.
Work through the warnings: move custom properties under `config.meta`, move `freshness`, `meta`, `tags`, `docs`, `group`, and `access` under `config:`, relocate standalone anchors, remove duplicate keys and orphaned Jinja blocks, and replace `-m` with `-s` in Bolt commands. The [`dbt-autofix` tool](https://github.com/dbt-labs/dbt-autofix) or the [DinoAI upgrade agent](/guides/migrations/dbt-version-upgrades/upgrade-with-the-dinoai-agent) automates most of this.
If any schedule runs with `--warn-error` or `--warn-error-options`, decide whether deprecations should fail it. Set `"warn": ["Deprecations"]` to keep them as warnings while you migrate.
In **Settings > Workspace > General**, select **Change version**, choose **1.10**, and save. See [Upgrade dbt Core™ version](/guides/upgrade-dbt-core-version).
`dbt --version` reports 1.10.x, Bolt schedules run green, and `dbt parse` output shows no deprecation warnings you haven't consciously deferred. The most likely failure is a `--warn-error` schedule newly failing on deprecation warnings; fix the code or add `"warn": ["Deprecations"]` to `warn_error_options`.
## Next steps
UDFs, and deprecation warnings switched on by default.
Automate the deprecation 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.9](/guides/migrations/dbt-version-upgrades/upgrade-to-dbt-1.9.md)
- [dbt™ version upgrades](/guides/migrations/dbt-version-upgrades/index.md)
- [Upgrade to dbt™ 1.11](/guides/migrations/dbt-version-upgrades/upgrade-to-dbt-1.11.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)