ref() targets from the latest manifest.json of a production Bolt schedule. This speeds up iteration on downstream models.
Open the selector from the Defer control in the bottom panel, next to the Run button.
Options
What it affects
When Defer to Production is enabled, it applies across the IDE:- Data Explorer: both Preview Data and Compiled SQL use the deferred production state.
- Terminal dbt™ commands automatically defer to the selected production manifest.
PrerequisitesDefer to Production needs a connected Scheduler Environment and at least one active Bolt schedule. To defer to an environment, the latest run of at least one of its schedules must have passed. Turbo CI schedules don’t count.
How --defer resolves ref() calls
When you defer, dbt™ resolves each ref() based on two questions:
- Is the referenced node included in the current run’s model selection?
- Does the referenced node exist as a database object in your development environment?
ref() using the namespace from the production schedule’s state manifest, so you read from production tables instead of building them in development. Paradime always fetches the latest manifest.json for the schedule or environment you selected, so you defer against the most current production state.
Using --favor-state
Choose Defer to Production —favor-state if you always want to read from the production manifest, even when the model already exists in your development environment. This maximizes consistency with production while you develop.
Deferred vs standard run
The compiled SQL for the same model shows the difference. With defer enabled,ref() resolves to the production schema (dbt_prod):
dbt_fabio):
Viewing the deferred schedule
After running a dbt™ command with defer enabled, the Terminal output says what it defers to, the schedule or the environment, with a clickable URL that opens the production run it uses in the Bolt UI.Read about dbt™‘s state comparison caveats and limitations.