# About dbt run command

## Overview

The `dbt run` command only applies to models. It doesn't run tests, snapshots, seeds, or other resource types. To run those commands, use the appropriate dbt commands found in the [dbt commands](../dbt-commands.md) section — such as `dbt test`, `dbt snapshot`, or `dbt seed`. Alternatively, use `dbt build` with a [resource type selector](../node-selection/methods.md#resource_type).

You can use the `dbt run` command when you want to build or rebuild models in your project.

### How does `dbt run` work?

* `dbt run` executes compiled SQL model files against the current `target` database.
* dbt connects to the target database and runs the relevant SQL required to materialize all data models using the specified materialization strategies.
* Models are run in the order defined by the dependency graph generated during compilation. Intelligent multi-threading is used to minimize execution time without violating dependencies.
* Deploying new models frequently involves destroying prior versions of these models. In these cases, `dbt run` minimizes downtime by first building each model with a temporary name, then dropping and renaming within a single transaction (for adapters that support transactions).

## Refresh incremental models

If you provide the `--full-refresh` flag to `dbt run`, dbt will treat incremental models as table models. This is useful when

1. The schema of an incremental model changes and you need to recreate it.
2. You want to reprocess the entirety of the incremental model because of new logic in the model code.

bash

```shell
dbt run --full-refresh
```

You can also supply the flag by its short name: `dbt run -f`.

In the dbt compilation context, this flag will be available as [flags.FULL\_REFRESH](../dbt-jinja-functions/flags.md). Further, the `is_incremental()` macro will return `false` for *all* models in response when the `--full-refresh` flag is specified.

models/example.sql

```sql
select * from all_events

-- if the table already exists and `--full-refresh` is
-- not set, then only add new records. otherwise, select
-- all records.
{% if is_incremental() %}
   where collector_tstamp > (
     select coalesce(max(max_tstamp), '0001-01-01') from {{ this }}
   )
{% endif %}
```

## Running specific models

dbt will also allow you select which specific models you'd like to materialize. This can be useful during special scenarios where you may prefer running a different set of models at various intervals. This can also be helpful when you may want to limit the tables materialized while you develop and test new models.

For more information, see the [Model Selection Syntax Documentation](../node-selection/syntax.md).

For more information on running parents or children of specific models, see the [Graph Operators Documentation](../node-selection/graph-operators.md).

(Applies to dbt v2.0 and later)

## dbt Information Schema

Use `--generate-info-schema` to write the [dbt Information Schema](../../docs/build/dbt-information-schema.md) to `target/info_schema/` in a versioned subdirectory (currently `v1/`). The Information Schema exposes your project's metadata as queryable SQL tables (similar to a database's `INFORMATION_SCHEMA`) so you can query models, sources, and more without parsing `manifest.json`.

```shell
dbt run --generate-info-schema
```

To populate column types and column-level lineage in `dbt.node_columns` and `dbt.column_lineage`, combine with [`--static-analysis strict`](../../docs/build/about-static-analysis.md). Without it, `dbt.node_columns` and `dbt.column_lineage` contain no column types and no lineage.

```shell
dbt run --generate-info-schema --static-analysis strict
```

## Treat warnings as errors

See [global configs](../global-configs/warnings.md)

## Failing fast

See [global configs](../global-configs/failing-fast.md)

## Enable or Disable Colorized Logs

See [global configs](../global-configs/print-output.md#print-color)

## The `--empty` flag

The `run` command supports the `--empty` flag for building schema-only dry runs. The `--empty` flag limits the refs and sources to zero rows. dbt will still execute the model SQL against the target data warehouse but will avoid expensive reads of input data. This validates dependencies and ensures your models will build properly.

## Status codes

When calling the [list\_runs api](https://docs.getdbt.com/dbt-cloud/api-v2#/operations/List%20Runs), you will get a status code for each run returned. The available run status codes are as follows:

* Queued = 1
* Starting = 2
* Running = 3
* Success = 10
* Error = 20
* Canceled = 30
* Skipped = 40