Skip to main content
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; check the dbt Core™ 1.9 changelog for the full detail.
Prerequisites
  • An Admin role 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 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.
Snowflake column size change (September 2026). Snowflake plans to increase 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:
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 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 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 sets a custom indicator (such as a future date) for dbt_valid_to on current records, instead of the default NULL.
  • 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 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 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:

​
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 with description.
  • ref and source work in foreign key 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

1

Prepare the project

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. Commit any dbt_project.yml flag changes before switching versions.
2

Test on 1.9 in a non-production environment

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.
3

Switch the workspace version

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.
4

Rebuild state for deferred runs

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

Upgrade to dbt™ 1.10

The next version introduces the deprecation warnings that pave the road to v2.

Upgrade with the DinoAI agent

Have an agent apply the project changes and validate the build for you.

Manage dbt™ version

The workspace setting and per-environment overrides.

Official v1.9 upgrade guide

The upstream dbt™ documentation this guide is based on.

Related topics

dbt™ version upgradesUpgrade to dbt™ 1.10Upgrade dbt Core™ versionUpgrade to dbt™ 1.12Upgrade to dbt™ 1.11