This is a companion discussion topic for the original entry at More time coding, less time waiting: Mastering defer in dbt | dbt Developer Blog
A very handy feature no doubt but one caveat to add is that in some scenarios using deferral to prod can push up your costs as opposed to saving costs.
Suppose the model you are working on has upstream models with non-prod behaviour in it’s code eg. like filtering massive source data to only the last x days (to save costs in development). By deferring to the production upstream models this could lead to much more data being processed in the development environment than was intended.
In short, one should always consider the impact of deferral over just running in that mode by default.
Nice succinct blog post explaining how to use dbt defer. This is a brief comment to highlight two potential typos which may be confusing to a new reader:
With a development version of model_a in our dev schema, dbt will preferentially use that version instead of deferring >>> I think you meant model_b??
model_c as (
select * from analytics.dbt_dconnors.model_b
),
I think the model_b should be model_c??