Features
In dbt, `dbt run` executes only model materializations, while `dbt build` runs models plus their tests, snapshots, and seeds in the right order.
`dbt run` materializes selected models and their downstream dependencies. `dbt build` performs the same materializations and also executes tests, snapshots, and seeds, giving you a fully validated DAG in one command.
Use `dbt build` during pull-request CI, nightly production jobs, or any time you need data + tests to succeed together.The single command shortens pipelines and prevents untested tables from reaching consumers.
Choose `dbt run` for rapid, iterative development on a subset of models. Skipping tests and snapshots keeps feedback loops fast when you only care about SQL logic changes.
`dbt build` walks the DAG twice—first to build, then to test—ensuring tests fire after all upstream models finish.`dbt run` scans once, so downstream tests might fail until you trigger them separately.
# Build a model, its children, and run tests
$ dbt build --select orders+
The `+` operator includes downstream models and their tests, making one command sufficient for CI pipelines.
Within Galaxy’s modern SQL editor you can author dbt models, run `dbt build` or `dbt run` in an integrated terminal, and let the AI copilot surface failing tests instantly—speeding up debugging.
Run `dbt build --select ` locally before opening a PR.Catching test failures early avoids noisy CI runs and broken production tables.
Enable `partial_parse: true` to shorten compile times.Both `dbt run` and `dbt build` benefit, but the speed gain is most noticeable for `dbt build` because it triggers more tasks.
jobs:
dbt-ci:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Install dbt
run: pip install dbt-core dbt-postgres
- name: Run full build
run: dbt build --profiles-dir ./profiles --select state:modified+
This GitHub Actions job builds only models changed in the PR plus their children, keeping CI times reasonable.
Using `dbt build` without `--select` can unintentionally test the entire project, slowing development.Always scope the selection.
Teams sometimes rely solely on `dbt run`, pushing untested tables to production. Schedule `dbt build` nightly or in CI to ensure quality.
`dbt build` generally runs longer than `dbt run` due to tests and snapshots. Account for the extra time in SLAs and DAG scheduling.
.
Testing and data freshness are critical in analytics engineering. Relying only on `dbt run` can surface bad data to stakeholders because tests are skipped. `dbt build` enforces test execution and validates snapshots, making pipelines more reliable without extra orchestration. Choosing the right command saves compute. During development, running full `dbt build` wastes resources; in production, skipping it risks quality. Understanding the trade-offs lets engineers strike the perfect balance.
Functionally yes—`dbt build` covers everything `dbt run` does plus tests, seeds, and snapshots. You can standardize on `dbt build` for production while still using `dbt run` for fast local loops.
Yes. Use the `--threads` flag or configure `threads:` in `profiles.yml`. dbt will parallelize model builds and tests where dependencies allow.
Galaxy’s IDE lets you edit models, run `dbt build` in an integrated terminal, and use the AI copilot to auto-fix failing tests without context switching.
There is extra overhead from tests and snapshots. Mitigate it by scoping selections, using incremental models, and enabling partial parsing.
.avif){kind=logo}
