> ## 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.9
> Move your Paradime workspace to dbt Core™ 1.9: microbatch incremental models, redesigned snapshots, new behavior flags, and a Snowflake breaking change.
dbt Core™ 1.9 adds the microbatch incremental strategy and a redesigned snapshot experience. This guide summarizes what changes, what can break, and how to switch your Paradime workspace over. It is based on the official [dbt™ upgrade guide for v1.9](https://docs.getdbt.com/docs/dbt-versions/core-upgrade/upgrading-to-v1.9); check the [dbt Core™ 1.9 changelog](https://github.com/dbt-labs/dbt-core/blob/1.9.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 currently on dbt™ 1.8. Upgrade one minor version at a time.
Estimated time: 30 minutes, plus project testing.
## What can break
dbt Labs maintains backward compatibility across all 1.x versions, and behavior changes ship behind [behavior change flags](https://docs.getdbt.com/reference/global-configs/behavior-changes) so existing projects get a migration window. Two things still deserve a check before you switch:
**Snowflake `target.account` change.** When upgrading from dbt™ 1.8 to 1.9, `{{ target.account }}` replaces underscores with dashes: an account set to `sample_company` now compiles to `sample-company`. If your project builds identifiers or URLs from `target.account`, update that logic. See the [dbt-snowflake issue](https://github.com/dbt-labs/dbt-snowflake/issues/1286).
**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. `dbt-snowflake` versions below 1.10.6 may fail to build incremental models that have string columns with collation defined and use `on_schema_change='sync_all_columns'`. Check whether you are affected:
```bash theme={"system"}
dbt ls -s config.materialized:incremental,config.on_schema_change:sync_all_columns --resource-type model
```
If the command returns models, plan to move to a dbt™ version that includes `dbt-snowflake` 1.10.6 or later.
## What's new in dbt™ 1.9
### Microbatch incremental strategy
The new [microbatch strategy](https://docs.getdbt.com/docs/build/incremental-microbatch) processes large event datasets in discrete time-based batches, each with its own query, instead of one query for all new data:
* Write your model query for a single batch; dbt™ generates the time filters from your `event_time`, `lookback`, and `batch_size` configurations.
* Batches run independently, so failures are isolated and `dbt retry` reloads only the failed batches.
* Reprocess specific windows with the `--event-time-start` and `--event-time-end` CLI arguments.
* Batches that can run in parallel do so automatically, with a manual override via the [`concurrent_batches`](https://docs.getdbt.com/reference/resource-properties/concurrent_batches) config.
Microbatch is supported on the postgres, redshift, snowflake, bigquery, spark, and databricks adapters.
If you use a custom microbatch macro, set the `require_batched_execution_for_custom_microbatch_strategy` behavior flag to `true` in `dbt_project.yml` to enable batched execution. Without a custom macro, no flag is needed.
### Snapshot improvements
Snapshots become easier to configure, run, and customize:
* Snapshots can now be defined in YAML files, a cleaner and more consistent specification.
* `snapshot_meta_column_names` customizes the names of the meta fields dbt™ adds (`dbt_valid_from`, `dbt_valid_to`, and so on).
* `target_schema` is now optional; when omitted, snapshots use the schema of the current environment.
* Standard `schema` and `database` configs are supported, consistent with other resource types.
* dbt™ warns when the configured `updated_at` field is not the proper data type or timestamp.
* [`dbt_valid_to_current`](https://docs.getdbt.com/reference/resource-configs/dbt_valid_to_current) sets a custom indicator (such as a future date) for `dbt_valid_to` on current records, instead of the default `NULL`.
* [`hard_deletes`](https://docs.getdbt.com/reference/resource-configs/hard-deletes) controls how deleted source rows are handled: `ignore` (default), `invalidate` (replaces the legacy `invalidate_hard_deletes=true`), or `new_record`, which tracks hard deletes by adding a new record.
To migrate existing snapshots safely, follow the [snapshot configuration migration](https://docs.getdbt.com/reference/snapshot-configs#snapshot-configuration-migration) reference.
### Properties moved to configs (backported)
Three properties became configs in dbt™ 1.10 and were backported to 1.9: `freshness` for sources, and `meta` and `tags` under `columns`. You can start moving them under `config:` now; the [1.10 guide](/guides/migrations/dbt-version-upgrades/upgrade-to-dbt-1.10) covers the full list.
### `state:modified` improvements
Environment-aware improvements reduce false positives and negatives in `state:modified` selection, for example when a model is materialized as a table in prod but a view in dev. The improvement is unlocked by the `state_modified_compare_more_unrendered_values` behavior flag below.
### New behavior flags
dbt™ 1.9 introduces these flags, all disabled by default. Opt in by setting them to `true` under `flags:` in `dbt_project.yml`:
| Flag | What it does when enabled |
| ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `state_modified_compare_more_unrendered_values` | Compares unrendered config values during `state:modified` checks, reducing false positives from environment-aware Jinja. Requires rebuilding your state directory first; without a rebuild, `state:modified` may select nodes that haven't actually changed. |
| `skip_nodes_if_on_run_start_fails` | If any `on-run-start` hook fails, all selected nodes are marked as skipped. Hooks themselves always run regardless of previous outcomes. |
| `require_nested_cumulative_type_params` | Errors (instead of warns) when cumulative metrics are not formatted with the new `cumulative_type_params` nesting. |
| `require_batched_execution_for_custom_microbatch_strategy` | Enables batched execution for projects with a custom microbatch macro. |
### Adapter-specific changes
* **Redshift**: supports IAM Role authentication.
* **Snowflake**: Iceberg table format support on the table, incremental, and dynamic table materializations, plus the `target.account` change flagged above.
* **BigQuery**: running queries can be cancelled on keyboard interrupt, and intermediate tables created by incremental models are auto-dropped to save resources.
* **Spark**: the ODBC driver connection string can be overridden for custom connections.
### Quick hits
* Removing a contracted model (deleting, renaming, or disabling it) now raises an error for versioned models and a warning for unversioned ones.
* [Data tests can be documented](https://docs.getdbt.com/reference/resource-properties/description) with `description`.
* `ref` and `source` work in [foreign key constraints](https://docs.getdbt.com/reference/resource-properties/constraints).
* `dbt test` accepts `--resource-type` / `--exclude-resource-type` to include or exclude data tests (`test`) or unit tests (`unit_test`).
* The `enabled` config is available on unit tests, defaulting to `true`.
## Upgrade steps
Check the two Snowflake warnings above, review the behavior flags you want to opt into, and if you plan to adopt the YAML snapshot format, follow the [snapshot migration reference](https://docs.getdbt.com/reference/snapshot-configs#snapshot-configuration-migration). Commit any `dbt_project.yml` flag changes before switching versions.
Pin a Bolt environment to dbt™ 1.9 in **Settings > Environments** (leave production on **Inherit workspace default**) and run your main schedules against it, or switch the workspace version in a staging workspace first. See [Create and manage environments](/products/settings/connections/index#create-and-manage-environments).
In **Settings > Workspace > General**, select **Change version**, choose **1.9**, and save. Every user's Code IDE and every Bolt schedule that inherits the workspace default now runs 1.9. See [Upgrade dbt Core™ version](/guides/upgrade-dbt-core-version).
If you enable `state_modified_compare_more_unrendered_values`, regenerate the manifests your deferred and Turbo CI runs compare against by running the production schedule once on 1.9 before relying on `state:modified` selection.
`dbt --version` in the Code IDE terminal reports 1.9.x, `dbt parse` and `dbt build` complete without new errors, and your Bolt schedules run green. The most likely failure is Snowflake code that depended on `target.account` containing underscores; search your project for `target.account` if compiled identifiers look wrong.
## Next steps
The next version introduces the deprecation warnings that pave the road to v2.
Have an agent apply the project changes and validate the build for you.
The workspace setting and per-environment overrides.
The upstream dbt™ documentation this guide is based on.
## Related topics
- [dbt™ version upgrades](/guides/migrations/dbt-version-upgrades/index.md)
- [Upgrade to dbt™ 1.10](/guides/migrations/dbt-version-upgrades/upgrade-to-dbt-1.10.md)
- [Upgrade dbt Core™ version](/guides/upgrade-dbt-core-version.md)
- [Upgrade to dbt™ 1.12](/guides/migrations/dbt-version-upgrades/upgrade-to-dbt-1.12.md)
- [Upgrade to dbt™ 1.11](/guides/migrations/dbt-version-upgrades/upgrade-to-dbt-1.11.md)