If you’re building analytics pipelines with dbt, choosing between dbt run and dbt build matters more than it sounds. Pick the wrong command and you risk longer feedback loops, higher warehouse spend, and missed tests in production. Pick the right one and you get fast developer iteration, tight CI checks, and consistent data quality.

In this guide, we clarify dbt run vs dbt build with practical examples, a decision tree, and our CI/CD playbook. Our stance from dozens of dbt implementations: use run for local development and targeted debugging; use build for CI and production to orchestrate models, seeds, snapshots, and tests in DAG order.

We’ll also show how to combine state:modified, –defer, and the –empty flag for lean, cost-effective pipelines.

Quick answer

• dbt run executes only the selected models. It does not run tests, seeds, or snapshots. It works well for targeted, fast development.
• dbt build orchestrates the selected resources, including models, seeds, snapshots, and tests, in DAG order. It enforces data quality and skips unsafe downstream builds when critical tests fail.

Authoritative references:

• See the “dbt run command” docs: https://docs.getdbt.com/reference/commands/run
• See the “dbt build command” docs: https://docs.getdbt.com/reference/commands/build

At-a-glance differences

• Scope:
  • run: Models only.
  • build: Models + seeds + snapshots + tests, all in graph order.
• Tests:
  • run: Does not run tests by default. You must run dbt test separately.
  • build: Runs unit tests (pre-materialization) and data tests (post-materialization) automatically. See “dbt unit tests”: https://docs.getdbt.com/docs/build/unit-tests
• Failure handling:
  • run: Keeps running selected models unless you stop or use –fail-fast.
  • build: If critical tests fail, dbt skips downstream nodes to avoid propagating bad data.
• Typical use:
  • run: Local dev, targeted re-runs, incremental model debugging.
  • build: CI/PR checks, production jobs, end-to-end validation.
• Cost and speed:
  • run: Fast, minimal. No tests.
  • build: More thorough, and you can optimize it with state:modified, –defer, and –empty for CI.
• Flags overlap:
  • Both support selection syntax, –fail-fast, and the new “–empty flag” (schema-only validation that limits refs/sources to zero rows): https://docs.getdbt.com/docs/build/empty-flag

Execution flow and materializations

dbt run compiles and executes only the selected SQL models against your target. It respects each model’s materialization (view, table, incremental). DAG order still applies for the selected set, but dbt doesn’t run tests or touch seeds/snapshots.

• Views: dbt creates or replaces views of the compiled SQL.
• Tables: dbt creates or replaces physical tables.
• Incremental models: dbt merges new or changed data based on your is_incremental() logic and the model’s config:materialized setting.
• Full refresh: If you pass –full-refresh, dbt rebuilds incremental tables from scratch. Use with care on large datasets.

More details in the “dbt run command” docs: https://docs.getdbt.com/reference/commands/run

Common flags (–full-refresh, –select, –empty)

• –full-refresh: Force rebuild of incremental tables. Good for schema changes, bad for cost if overused.
• –select: Target specific models/domains/tags using dbt selection syntax: https://docs.getdbt.com/reference/node-selection/syntax
• –empty: Validate DAG and model SQL while limiting refs/sources to zero rows. This works well for CI dry runs: https://docs.getdbt.com/docs/build/empty-flag

When to use dbt run (local dev, targeted)

• Iterating on a single model or domain.
• Debugging incremental logic or performance.
• Running a quick full-refresh on a subset of models (off-hours).

Example commands and expected output

Local development:

dbt run –select my_model+

Rebuild only incremental-tagged models:

dbt run –full-refresh –select tag:incremental

Schema-only dry run (CI sanity check):

dbt run –select my_domain.* –empty –fail-fast

Expected: Models materialize in selection order respecting dependencies; no tests run.

Models, seeds, snapshots, tests in DAG order

dbt build orchestrates all resource types for your selection:

• seeds: Load CSVs defined in your project (equivalent to dbt seed).
• snapshots: Apply snapshot logic to track slowly changing dimensions.
• models: Materialize views/tables/incrementals.
• tests: Run in correct order relative to model builds.

See “dbt build command”: https://docs.getdbt.com/reference/commands/build

Test behavior – unit tests pre-materialization, data tests post

• Unit tests: Execute before materializing a SQL model, using a small, static set of inputs to validate logic quickly. Reference: https://docs.getdbt.com/docs/build/unit-tests
• Data tests: Execute after models are built, validating expectations such as not_null, unique, relationships, and custom SQL tests.

This ordering ensures you catch logic errors early and data quality issues before downstream models build.

Skipping downstream on test failures and severity control

When a critical test fails, dbt build will skip downstream nodes rather than continue building on top of broken data. You can also mark certain tests with severity: warn so build proceeds while still surfacing issues.

Example log snippet:

When to use dbt build (production, CI)

• CI/PR checks to validate changes end-to-end.
• Nightly or hourly production jobs orchestrating seeds, snapshots, models, and tests.
• Domain-specific builds where data quality is non-negotiable.

Example commands and expected output

CI Slim build (fast feedback):

dbt build –select “state:modified+” –defer –state path/to/prod_artifacts –fail-fast –empty

Nightly production:

dbt build –selector nightly_domain

Expected: Seeds/snapshots/models/tests run in graph order. Failing critical tests stop unsafe downstream work.

Local development and debugging

Pick run for speed and focus. A few patterns we rely on:

• Work on a node with children:
  • dbt run –select my_model+
• Include parents to ensure inputs compile:
  • dbt run –select +my_model
• Test incrementals with a full reload (off-hours on big tables):
  • dbt run –full-refresh –select tag:incremental
• Dry-run validation without data scans:
  • dbt run –select my_domain.* –empty –fail-fast

Pull request checks (Slim CI state:modified + –defer + –empty)

Goal: Validate only what changed and its immediate graph neighborhood, while deferring to production artifacts for everything else.

• state:modified+: Select changed nodes plus their children.
• –defer: Use already-built production objects for ancestors you didn’t change. See “defer and Slim CI”: https://docs.getdbt.com/reference/node-selection/defer
• –state: Point to production artifacts (manifest.json and run_results.json) generated by the last prod deploy.
• –empty: Validate graph and SQL with zero-row refs/sources to minimize cost.
• –fail-fast: Stop on first failure for faster feedback.

Command:

dbt build –select “state:modified+” –defer –state path/to/prod_artifacts –fail-fast –empty

Persist manifest.json and run_results.json from production after each deploy so CI has accurate state.

Nightly production jobs (full DAG vs partial)

• Full DAG per domain:
  • dbt build –selector nightly_domain
• Split domains or tiers for isolation and parallelism.
• Run source freshness separately:
  • dbt source freshness
  • Many teams keep freshness outside build for clearer SLOs and alerting.

Incremental models and full-refresh workflows

• Normal cadence: Incremental merges via is_incremental().
• Full-refresh only when needed (schema changes, logic shifts):
  • dbt build –full-refresh –select tag:incremental
• Consider staggered full-refresh schedules for large tables to limit cost/spikes.

See “dbt selection syntax”: https://docs.getdbt.com/reference/node-selection/syntax

Graph operators (+, @) and practical recipes

• Children of a node:
  • my_model+
• Parents of a node:
  • +my_model
• Parents and children (neighbors):
  • @my_model
• Domain patterns:
  • models/staging/*
• Tags and configs:
  • tag:incremental or config:materialized:incremental

Combine operators to express intent clearly:

• “Build my model and its parents and children”:
  • +my_model+

State-aware selections (state:modified)

• Only changed nodes and their children:
  • state:modified+
• Combine with domain/tags:
  • state:modified+ tag:finance

This is the backbone of Slim CI.

Excluding tests or resource types

• Exclude tests if you’re doing a quick model-only run:
  • –exclude test_type:*
• Or select only a resource type:
  • resource_type:model or resource_type:test
• Indirect-selection modes (configured in selectors.yml) control how dbt grabs related nodes/tests (eager vs cautious). Tune these to speed up CI while retaining safety.

We standardize on build for CI and prod, with state-aware selections to keep runs fast and cheap.

Minimal PR job (fast feedback)

• Use Slim CI: state:modified+, –defer, –state, –empty, –fail-fast.
• Persist prod artifacts (manifest.json, run_results.json) after successful deploys.
• Keep the environment fast: warm dependencies (dbt deps) and cache warehouse auth.

Example GitHub Actions:

Pre-merge gating and data quality

• Require build to pass (including unit and data tests).
• Mark non-critical tests severity: warn to avoid noisy flakes blocking merges.
• Optionally add dbt docs generate as an artifact for reviewer context.

Production job stages and rollbacks

• Stage 1: Seeds and snapshots
• Stage 2: Models
• Stage 3: Data tests and reporting checks
• On failure: Build skips downstream automatically; notify and triage. Consider re-running subsets or using a known-good selector to roll back just affected domains.

If you orchestrate with Airflow, dbt Cloud operators make it straightforward: https://airflow.apache.org/docs/apache-airflow-providers-dbt-cloud/stable/operators.html

For more end-to-end process design and templates, see our dbt project structure conventions post: https://stellans.io/dbt-project-structure-conventions/

Running dbt run without tests in prod

Symptom: Silent data quality regressions. Fix: Use dbt build in prod to run unit/data tests in order and skip unsafe downstream work.

Misusing full-refresh on large tables

Symptom: Cost spikes and long jobs. Fix: Reserve –full-refresh for schema/logic changes and schedule off-hours; prefer incremental merges.

Over-selecting resources and long runtimes

Symptom: Slow CI and high spend. Fix: Use state:modified+, tags, and domain-specific selectors. In CI, combine –defer and –empty for zero-row validation.

• Local feature work:
  • dbt run –select my_model+
  • Outcome: Only your model and its children materialize. No tests.
• Incremental model schema change:
  • dbt run –full-refresh –select tag:incremental
  • Outcome: Rebuild targeted incrementals from scratch.
• PR checks (Slim CI):
  • dbt build –select “state:modified+” –defer –state path/to/prod_artifacts –fail-fast –empty
  • Outcome: Unit tests run first, then downstream data tests; dbt skips unsafe downstream work on failures.
• Nightly production by domain:
  • dbt build –selector nightly_domain
  • Outcome: Seeds, snapshots, models, and tests run in DAG order for that domain.

When using –empty, dbt limits ref() and source() to zero rows. This is ideal for CI, but be careful if your SQL relies on wildcard tables or _TABLE_SUFFIX logic. Ensure your selection and test queries don’t inadvertently trigger wide wildcard scans. A refresher on BigQuery wildcard behavior: https://cloud.google.com/bigquery/docs/querying-wildcard-tables

• dbt test: Runs only tests; useful when re-checking known issues.
• dbt seed: Loads CSVs as tables; dbt build will orchestrate seeds for you.
• dbt snapshot: Manages SCD logic; included in build orchestration.
• dbt run-operation: Executes macros for admin/data tasks (e.g., backfills). Keep this separate from build/run to avoid surprises in prod.

See “Run your dbt projects” overview: https://docs.getdbt.com/docs/running-a-dbt-project/run-your-dbt-projects

• Use run for local development loops; switch to build before merging to validate end-to-end.
• In CI, combine state:modified + –defer + –empty + –fail-fast for fast, cheap checks.
• In production, prefer build to enforce data quality and skip unsafe downstream nodes.
• Persist production artifacts (manifest.json, run_results.json) to power Slim CI.
• Keep source freshness in a separate job for clear alerts and ownership.
• Use severity: warn for non-critical checks to avoid blocking pipelines unnecessarily.

Community perspective: “production command patterns” discussion: https://discourse.getdbt.com/t/the-exact-dbt-commands-we-run-in-production/6692

• What is the difference between dbt run and dbt build?
  • dbt run executes selected models only. dbt build orchestrates models, seeds, snapshots, and tests in DAG order, with unit tests before model materialization and data tests after.
• Does dbt build run tests automatically?
  • Yes. dbt build runs unit tests before building each resource and data tests after, then skips downstream nodes if critical tests fail.
• When should I use dbt build instead of dbt run?
  • Use build in CI and production to enforce quality. Use run locally for quick, targeted development and debugging.
• Is dbt build slower than dbt run?
  • It can be, since it includes tests, seeds, and snapshots. In CI, combine state:modified, –defer, –empty, and –fail-fast to keep it fast.
• Does dbt build include seeds and snapshots?
  • Yes. dbt build orchestrates seeds and snapshots along with models and tests.
• How do I run only changed models with dbt build?
  • dbt build –select “state:modified+” –defer –state path/to/prod_artifacts –fail-fast –empty
• What does the –empty flag do?
  • It performs schema-only builds with zero-row refs/sources. You validate DAG integrity while minimizing data scans. This approach is ideal for CI.
• Should I use dbt build in production?
  • Typically yes. It enforces tests and skips unsafe downstream builds on failures. Run source freshness in a separate job as needed.

We design dbt workflows that balance speed and safety: fast developer loops, fast CI feedback, and safe production runs. Our implementations standardize on Slim CI, resilient domain selectors, and clear test severity, which reduces spend while improving reliability.

• How we design robust dbt workflows
  • We model projects for clarity (staging → intermediate → marts), adopt state-aware CI, and right-size materializations. For a starting point, see our dbt project structure conventions: https://stellans.io/dbt-project-structure-conventions/
• Contact and services
  • Want help architecting dbt development, CI, and production jobs? Explore our dbt development services: https://stellans.io/services/ and Contact Stellans via our services page to book a consultation: https://stellans.io/services/

Use dbt run to move fast in development; use dbt build to ship safely in CI and production. Add Slim CI patterns such as state:modified, –defer, and –empty to cut PR feedback time and warehouse costs without sacrificing quality. The payoff: fewer failed runs, faster delivery, and trusted downstream reporting.

Want help designing reliable dbt pipelines? We’ll work with you to streamline CI/CD, reduce spend, and ship trusted datasets. Explore our dbt development services: https://stellans.io/services/ or Contact Stellans to discuss your roadmap: https://stellans.io/services/

External references cited above:

• dbt run command: https://docs.getdbt.com/reference/commands/run
• dbt build command: https://docs.getdbt.com/reference/commands/build
• –empty flag: https://docs.getdbt.com/docs/build/empty-flag
• dbt selection syntax: https://docs.getdbt.com/reference/node-selection/syntax
• defer and Slim CI: https://docs.getdbt.com/reference/node-selection/defer
• dbt unit tests: https://docs.getdbt.com/docs/build/unit-tests
• Production command patterns: https://discourse.getdbt.com/t/the-exact-dbt-commands-we-run-in-production/6692
• Airflow dbt Cloud operators: https://airflow.apache.org/docs/apache-airflow-providers-dbt-cloud/stable/operators.html
• BigQuery _TABLE_SUFFIX wildcard tables: https://cloud.google.com/bigquery/docs/querying-wildcard-tables