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 an existing Bolt schedule with Defer to a previous run enabled.
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 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 includes the deferred schedule’s details, with a clickable URL that opens the production run in the Bolt UI.Read about dbt™‘s state comparison caveats and limitations.