dbt Model Versioning

Load when task involves dbt model versioning, creating v2 of a model, or backward-compatible model changes. Covers versions YAML config, defined_in, latest_version, and ref() with version pins.

Sby Skills Guide Bot
DevelopmentIntermediate
007/22/2026
Claude CodeCursorWindsurfCopilotCodex
#dbt#model-versioning#data-engineering#sql#yaml

Recommended for


name: dbt-versioning description: "Load when task involves dbt model versioning, creating v2 of a model, or backward-compatible model changes. Covers versions YAML config, defined_in, latest_version, and ref() with version pins." disable-model-invocation: false allowed-tools: Bash(dbt *)

dbt Model Versioning

1. Versioned Model vs Standalone Copy

When a task says "create a v2," "add a new version," or "backward-compatible change," use dbt's native versions: config (dbt-core 1.6+). Do NOT create a standalone model with a _v2 suffix - that produces a separate node (model.project.dim_customers_v2) instead of a version node (model.project.dim_customers.v2).

2. YAML Structure

Declare versions inside the model's .yml file under the model entry:

models:
 - name: dim_customers
    latest_version: 1
    versions:
 - v: 1
 - v: 2
        defined_in: dim_customers_v2

Rules:

  • versions: is a list of v: entries inside the models: block, under the model name.
  • defined_in: maps a version to its SQL filename (without .sql). Omit defined_in when the filename matches the default <model_name>_v<N>.sql.
  • latest_version: controls which version ref('dim_customers') resolves to. If the task says "not yet the primary version," set latest_version to the old version number.

3. File Naming

Version SQL files use the pattern <model_name>_v<N>.sql.

  • dim_customers.sql - original model, becomes v1 implicitly.
  • dim_customers_v2.sql - new version.

Do NOT rename or move the original SQL file. It remains v1 without changes.

4. How ref() Works with Versions

  • ref('dim_customers') resolves to whichever version latest_version specifies.
  • ref('dim_customers', v=2) pins to version 2 regardless of latest_version.

Downstream models that need the new version must use ref('dim_customers', v=2). Models using bare ref('dim_customers') continue to get the old version until latest_version is updated.

5. Writing the v2 SQL

Read the original model's SQL first. If the v2 only renames or adds columns, write a thin wrapper:

select
    customer_id,
    customer_name,
    account_status as customer_status  -- renamed column
from {{ ref('dim_customers', v=1) }}

Do NOT duplicate all upstream logic into the v2 file when a SELECT-with-renames suffices.

6. Verification

After creating the versioned model, run:

dbt ls --select dim_customers --output json

Confirm the output contains nodes model.<project>.dim_customers.v1 and model.<project>.dim_customers.v2. If these nodes are missing, the versions: YAML is wrong.

Rules

  • NEVER create a standalone _v2 model without versions: YAML - dbt will not register it as a version.
  • NEVER rename or move the original SQL file when adding a new version.
  • ALWAYS set latest_version explicitly - omitting it defaults to the highest version number, which may break downstream refs.
  • ALWAYS read test files in tests/ before writing models - they reveal required dbt features the task may only hint at.
Related skills