how to speed up dbt runs with selectors

TL;DR

Stop rebuilding the whole project on every run. Selectors let you run exactly the models you changed plus everything downstream of them, which turns a forty minute run into a four minute one. Learn the graph operators and state selection once and every future run gets faster, including CI.

how to speed up dbt runs with selectors

Use this when

• a full dbt run takes too long for iterative development
• CI rebuilds everything on every pull request
• you want to test one model and its downstream dependents

Not for this skill when

• the run is slow because of one bad query, profile that query instead
• the warehouse itself is undersized, selectors cannot fix that
• you need faster tests specifically, tag and select them separately

Steps

1. Run one model and everything downstream that depends on it, the most common daily pattern:

dbt run --select stg_orders+

Expected output: stg_orders builds, then every model downstream of it. The trailing + means "and all children", which catches everything your change affects.

1. Run a model plus everything upstream it needs when the model is fine but its inputs are stale:

dbt run --select +fct_orders

Expected output: all ancestors of fctorders build first, then fctorders itself. The leading + means "and all parents", which refreshes the inputs.

1. Tag models by cadence or domain and select by tag to carve the project into runnable slices:

dbt run --select tag:daily --exclude tag:slow

Expected output: only daily-tagged models run, minus the slow ones. Tags live in model config blocks, and --exclude takes the same selector syntax as --select.

1. In CI, run only what changed plus downstream, deferring everything else to production data URIs

dbt run --select state:modified+ --defer --state ./prod-artifacts

Expected output: changed models and their children build against production data for the rest. This is slim CI and it is the single biggest CI speedup most teams can get.

1. Combine selectors for the critical path when you need models plus their tests together:

dbt build --select tag:critical+

Expected output: the critical models, their downstream dependents, and the tests attached to all of them. One command for the "did I break anything important" check before a deploy.

1. Raise threads to actually use your warehouse parallelism once the selection is right:

dbt run --select tag:daily --threads 8

Expected output: up to 8 models build concurrently. Match threads to what your warehouse and connection limits allow, more threads than the warehouse can handle just queues inside the database.

Variant phrasings

dbt select specific models to run

The --select flag with model names is the starting point. Add + operators when dependents or ancestors matter to the result.

dbt run only changed models

That is state:modified with --state pointing at a previous manifest. Pair it with + to catch downstream effects of the change.

dbt exclude models from run

--exclude takes the same selector syntax as --select. Excluding slow or experimental models keeps daily runs tight without touching any code.

Why it happens

dbt builds a dependency graph of every model, and a bare dbt run walks the whole thing. Most runs only need a slice: what you touched and what depends on it. Selectors are just a query language over that graph, so a precise selection skips everything irrelevant without breaking dependency order, which is why the speedup is free correctness-wise.

Edge cases

• State selection needs a manifest.json from the comparison point. No artifacts, no state selection, so keep the prod manifest fresh.
• Selectors do not cross project boundaries into installed packages unless you name the package explicitly.
• --defer still queries production for unselected models, which costs warehouse compute. It is cheaper than rebuilding, not free.
• Over-selecting with + on a hub model can pull in half the project. Preview with dbt ls --select before you run.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_b74aVgtMI4tGGnLMEa1pCQ