## 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.

```text
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:

```shell
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.

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

```shell
dbt run --select +fct_orders
```

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

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

```shell
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`.

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

```shell
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.

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

```shell
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.

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

```shell
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