dbt Model Versioning

VerifiedSafe

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
Data & AIIntermediate
8207/25/2026
Claude CodeCursorWindsurfCopilotCodex
#dbt#data-modeling#versioning#sql#analytics-engineering

Recommended for

Automated summary

This skill guides creating dbt model versions through the native `versions:` config instead of `_v2`-suffixed standalone copies.

Strengths

  • Explains the exact YAML structure (`versions:`, `defined_in`, `latest_version`) with a concrete example
  • Clearly separates a versioned node (`model.project.dim_customers.v2`) from a standalone `_v2` model
  • Details how `ref()` resolves with or without version pinning for downstream models
  • Provides a `dbt ls` command to confirm version nodes are registered

Limitations

  • Assumes dbt-core 1.6 or newer and does not address earlier versions
  • Does not cover version-level tests, model contracts, or intentional breaking changes
  • The YAML sample in the document has inconsistent indentation that may mislead
When to use it

Use it when a task asks for a dbt model v2 or a backward-compatible change that must keep existing `ref()` calls working.

When not to use it

Avoid it for deliberate breaking changes, full model rewrites, or dbt projects predating version 1.6.

Security analysis

Safe
Quality score82/100

The skill only instructs read and dbt CLI commands (dbt ls) within an allowed dbt scope; no destructive, network exfiltration, or obfuscated actions.

No concerns found

How this analysis is made

Examples

Add a v2 with a renamed column
Create a v2 of dim_customers that renames account_status to customer_status, keeping v1 as the latest version for now.
Pin downstream model to v2
Update fct_orders to use version 2 of dim_customers while other models stay on the default version.
Verify versioned nodes
Check that dim_customers is properly registered as versions v1 and v2 in dbt.

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