How to defer to production in dbt Cloud

In a development schema most tables do not exist yet. Without deferral, building one model means building all its parents first. With deferral, dbt resolves every ref() to a model you have not built yourself to the production table, so you build only what you are changing.

Copy and paste

Studio IDE: turn on Defer to staging/production in the command bar.

dbt platform CLI: deferral is on by default. To turn it off for one command:

dbt build -s my_model --no-defer

Defer to a specific environment, for example a staging one:

# dbt_project.yml
dbt-cloud:
  project-id: '654321'
  defer-env-id: '123456'

Deploy and CI jobs: in the job’s settings, Compare changes against an environment, or against the job’s own last run.

How dbt resolves a ref()

With deferral on, for each model you did not select:

1. if your development schema has the model, dbt uses it;
2. otherwise, if a staging environment exists, dbt uses the staging table;
3. otherwise, it uses the production table.

dbt defers to one environment per command, staging or production, never both. --favor-state skips the first step and always uses the staging or production table, even when you have your own copy.

What deferral needs

• A production environment. In the environment’s settings, tick Production environment. Only one deployment environment per project can have it.
• A successful run there. Deferral reads the manifest of the last successful production job, CI jobs excluded. Before the first one, there is nothing to defer to.
• For staging: if a staging environment exists but no deploy job has run in it, deferral in the Studio IDE does not work, because dbt looks there first and finds no manifest.

When it helps and when it does not

• It helps when you change a model in the middle of a large project: you build that model, read its parents from production, and test the result in minutes.
• It misleads when your change depends on another change in a parent you did not build. dbt reads the old production version of the parent. Build both with -s +my_model in that case.
• Production data. A deferred development build reads production tables. Make sure your development role is allowed to read them.

The same mechanism works in dbt Core with --defer --state; see how to run only modified models.

Based on the dbt platform documentation (October 2026); not run against a live dbt account.