Selector methods return all resources that share a common property, using the
The "tag" method
tag: method is used to select models that match a specified tag.
$ dbt run --models tag:nightly # run all models with the `nightly` tag
The "source" method
source method is used to select models that select from a specified source. Use in conjunction with the
$ dbt run --models source:snowplow+ # run all models that select from Snowplow sources
The "path" method
path method is used to select models located at or under a specific path.
path prefix is not explicitly required, it may be used to make
# These two selectors are equivalentdbt run --models path:models/staging/githubdbt run --models models/staging/github# These two selectors are equivalentdbt run --models path:models/staging/github/stg_issues.sqldbt run --models models/staging/github/stg_issues.sql
The "package" method
package method is used to select models defined within the root project
or an installed dbt package. While the
package: prefix is not explicitly required, it may be used to make
# These three selectors are equivalentdbt run --models package:snowplowdbt run --models snowplowdbt run --models snowplow.*
The "config" method
config method is used to select models that match a specified node config.
$ dbt run --models config.materialized:incremental # run all models that are materialized incrementally$ dbt run --models config.schema:audit # run all models that are created in the `audit` schema$ dbt run --models config.cluster_by:geo_country # run all models clustered by `geo_country`
The "test_type" method
test_type method is used to select tests based on their type,
$ dbt test --models test_type:schema # run all schema tests$ dbt test --models test_type:data # run all data tests
The "test_name" method
test_name method is used to select schema tests based on the name of the
that defines it. For more information about how schema tests are defined, read about
custom schema tests.
$ dbt test --models test_name:unique # run all instances of the `unique` test$ dbt test --models test_name:equality # run all instances of the `dbt_utils.equality` test$ dbt test --models test_name:range_min_max # run all instances of a custom schema test defined in the local project, `range_min_max`
The "state" method
[β] Beta Feature
This is net-new functionality in v0.18.0, with iterative improvements to come. If you encounter unexpected behavior, please post in Slack or open an issue.
state method is used to select nodes by comparing them against a supplied
manifest. The file path of the comparison manifest must be specified via the
--state flag or
DBT_ARTIFACT_STATE_PATH environment variable.
state:new: There is no node with the same
unique_id in the comparison manifest
state:modified: Everything new, plus any changes to:
- file/node contents
- configs (
- descriptions (top-level and/or column-level, depending on
- database representations (user-input
alias, irrespective of
$ dbt test --models state:new # run all tests on new models + and new tests on old models$ dbt run --models state:modified # run all models that have been modified$ dbt ls --models state:modified # list all modified nodes (not just models)
N.B. State comparison works by identifying discrepancies between two manifests. Those discrepancies could be the result of:
- Changes made to a project in development
- Env-aware logic that causes different behavior based on the
target, env vars, etc.
dbt will do its best to capture only changes that are the result of development. In projects with intricate env-aware logic, dbt will err on the side of running too many models (i.e. false positives). We're working on better options for more complex projects, in the form of more-specific subselectors. Track this issue for progress.