Supported dbt commands and flags

The following table shows the dbt commands that are supported in dbt Projects on Snowflake. Any dbt command that isn’t listed here isn’t supported.

Note

Some features described on this page require a dbt project object that uses the mutable live version. To get a live-version object, opt in to the 2026_06 behavior change bundle or ask your Snowflake account representative to enable the separate single live version feature. Then create or replace the object, or migrate an existing versioned object with SYSTEM$MIGRATE_DBT_PROJECT. For details, see dbt Projects on Snowflake: dbt project objects migrate to a single mutable live version.

dbt Projects on Snowflake, supported dbt commands by execution method

dbt commandWorkspacesEXECUTE DBT PROJECTsnow dbt execute (CLI)
build

clean [3]

compile

deps [1]

docs generate [2]

list
parse
run

retry [3]

run-operation

seed

show

snapshot

source freshness [3]

test

[1] With AUTO_COMPILE = TRUE, Snowflake runs dbt compile during deployment. If an external access integration is configured, Snowflake first runs dbt deps, then dbt compile. Setting AUTO_COMPILE = FALSE skips both commands.

[2] dbt Projects on Snowflake don’t support dbt docs serve. To view your project’s documentation, use the dbt project object details page in Snowsight, or generate a static site with dbt docs generate --static. For more information, see Access dbt project documentation and artifacts.

[3] Requires a dbt project object that uses the mutable live version.

About flags

In dbt Core, you run commands (for example, dbt build) and modify their behavior with flags. Flags are configuration options that modify how a command behaves; some are command-specific, others are global. For more information, see flags.

You always run a command, and you attach flags to scope or alter it. For example, to run only incremental models and rebuild them, you would run the following command and flags:

dbt run --select config.materialized:incremental --full-refresh;

The --log-level-file flag is supported and controls the verbosity of dbt.log which our Snowsight UI uses; it defaults to debug, so pass --log-level-file info for quieter output.

The following flags aren’t supported in dbt Projects on Snowflake:

  • --profiles-dir
  • --project-dir
  • --log-format
  • --log-format-file

The paths specified by --target-path and --log-path must point to directories inside the project. Snowflake recommends pointing to dedicated subdirectories to avoid uploading unrelated project files with the execution results. The WRITEBACK setting controls whether an execution writes target and log artifacts to the live version. For concurrent executions with writeback enabled, use distinct, non-overlapping target and log directories. For details, see Use distinct target and log paths.

Clean a dbt project object

The clean command removes selected target directories from the live version. Cleanup is all or nothing. If Snowflake detects a protected path or files that change while cleanup is running, it stops, removes nothing, and returns an error.

The paths selected by clean depend on your dbt runtime and configuration:

  • If clean-targets is configured and you don’t pass --target-path, dbt cleans the configured paths.
  • If clean-targets isn’t configured, dbt uses its default clean targets and includes the path passed with --target-path.
  • If both clean-targets and --target-path are set, dbt Core cleans only the paths in clean-targets. dbt Fusion cleans the union of clean-targets and --target-path.

If you execute clean with WRITEBACK = FALSE, the command doesn’t update files on the live version. This is effectively a no-op. Files removed by clean cannot be recovered.