dbt run vs dbt build: Differences and How to Choose (Analytics Engineer Exam and Real-World Use)

Even if you know the commands, choosing between run and build during reviews or pre-production validation can get confusing. Real-world work demands fast iteration, CI needs reliable consistency, and the exam tests precise definitions.

This article follows the dbt official documentation to summarize the differences, how to choose, and how related features (selectors, incremental models, snapshots, tests) work together.

Core Differences: What Runs and When It Stops

dbt run targets models only. It compiles and executes the nodes specified by the selector. Tests do not run. Dependencies affect execution order, but unselected parent models are not automatically re-run (and missing parents cause a reference error).

dbt build runs the seeds, snapshots, and models within the selected scope in dependency order, and then runs the related tests (schema and data tests). In other words, it is a unified flow that builds and validates in a single command.

• dbt run: models only. Validation is handled separately by dbt test.
• dbt build: after building seeds/snapshots/models, the relevant tests run automatically.
• Both can scope work with selectors (-s/--select, with -m as an alias).

Execution flow of run vs build (conceptual)

Minimal example: single model vs integrated build

# Single model only (explicitly include parents with +)
dbt run -s +stg_orders

# Build and test the selected scope together
# Targets changed nodes and their downstream, plus related tests
dbt build -s state:modified+

Execution Order and Test Handling (Including Failure Behavior)

dbt controls parallelism and ordering based on the DAG. With build, tests tied to a node run only after that node finishes building. Tests for unselected nodes do not run.

When a test fails, the failure is recorded and other independent nodes continue running by default (use --fail-fast to stop early). Since run does not execute tests, failure detection depends on running test separately.

• Tests run after the node finishes, and only tests bound to assets within the selected scope.
• --fail-fast stops on the first failure; without it, dbt continues as far as possible.
• Both data tests (singular) and schema tests (generic) are executed by build.

Execution sequence of nodes and tests

Examples of schema and data tests

# models/schema.yml (generic test example)
models:
  - name: dim_customers
    columns:
      - name: customer_id
        tests:
          - not_null
          - unique

# tests/assert_positive_revenue.sql (singular test example)
-- A failure is aggregated as a build failure
select 1 where exists (
  select 1 from {{ ref('fct_revenue') }} where total_revenue < 0
);

# Run
# Executes schema and data tests against fct_revenue and dim_customers
dbt build -s dim_customers fct_revenue

Choosing Selectors: Fast and Safe with the Smallest Scope

For both run and build, selectors decide what gets targeted. The basics: include parents/children with +, pick by attribute with tag:, and capture change impact with state:.

With build, the difference is that tests are automatically attached to the selected scope. Tests bound to unselected nodes are not executed.

• +my_model includes upstream, my_model+ includes downstream, +my_model+ includes both
• state:modified+ targets changed nodes and their downstream (impact area), which is useful in CI
• Tune granularity with resource_type:, tag:, path:, config.materialized:, and so on

Scope differences by selector

A -> B -> C

-s B      : [B]
-s +B     : [A, B]
-s B+     : [B, C]
-s +B+    : [A, B, C]

Using the same selector for run and build

# Development loop (models only, fast)
dbt run -s +stg_orders

# CI (build and validate the impact area)
dbt build -s state:modified+ --defer --state target/manifest

Compatibility with Incremental Models and Snapshots

When selected, incremental models apply the delta in their default mode, while --full-refresh forces a full recompute. The behavior is identical under run or build.

Snapshots are independent nodes; once referenced, they are wired into the DAG. Because build can include snapshots in scope, it is well suited to integrated validation of models that depend on snapshots.

• incremental: when there is a large volume of changes, plan --full-refresh runs deliberately (watch out for locking and cost)
• snapshot: if included by the selector, build executes it; otherwise the existing table is referenced
• Because tests run against the produced output, you can validate health immediately after the update

Dependency between a snapshot and a model

Configuration example: incremental and snapshot

# models/fct_orders.sql
{{ config(materialized='incremental', unique_key='order_id') }}
select * from {{ ref('stg_orders') }}
{% if is_incremental() %}
  where updated_at > (select max(updated_at) from {{ this }})
{% endif %}

# snapshots/customers.sql
{% snapshot customers_scd %}
{{ config(strategy='timestamp', unique_key='customer_id', updated_at='updated_at') }}
select * from {{ source('app', 'customers') }}
{% endsnapshot %}

# Run
# Build and validate including the impact area
dbt build -s +dim_customers
# Full recompute (plan it carefully)
dbt run -s fct_orders --full-refresh

Decision Criteria for CI/CD and Production

For PR validation and pre-production consistency checks, dbt build is the first choice. It covers build and tests in one shot, so failures are detected early.

For local development and debugging, iterate quickly with dbt run on the smallest possible scope, and once the design lands, run build to also clear the tests. That is the most efficient flow.

• Development: verify fast with run, then build at milestones
• CI: use build -s state:modified+ --defer --state as the baseline
• Production batch: cover comprehensively with build; use --exclude to skip selected tests

A typical CI pipeline

Minimal GitHub Actions job example

jobs:
  dbt-ci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.11'
      - run: pip install dbt-core dbt-bigquery  # pick the adapter you need
      - run: dbt deps
      - run: dbt build -s state:modified+ --defer --state target

Pitfalls and Exam Focus Points

The exam tests strict definitions. In particular, lock in what dbt build targets, when tests run, and how unselected nodes are handled.

In practice, over- or under-selecting and overusing full-refresh cause cost spikes, locking, and false positives. Avoid them with rules and automation.

• Unselected parents are not automatically re-run. Add + or select them explicitly if needed.
• build runs tests, but tests bound to unselected nodes will not run.
• Plan full-refresh deliberately and watch the interaction between parallelism and locking.

Decision branches

Exam mini-check (self-quiz)

- dbt run: what runs? models only
- dbt build: what runs? seeds/snapshots/models + tests
- When do tests run? after the target node is built
- Include parents/children? extend the scope with +

Test Yourself

Frequently Asked Questions