Skip to main content
Versions 0.7.0 and later of prefect-dbt include the PrefectDbtRunner class, which provides an improved interface for running dbt Core commands with better logging, failure handling, and automatic asset lineage.
The PrefectDbtRunner is inspired by the DbtRunner from dbt Core, and its invoke method accepts the same arguments. Refer to the DbtRunner documentation for more information on how to call invoke.

Basic usage

When calling .invoke() in a flow or task, each node in dbt’s execution graph is reflected as a task in Prefect’s execution graph. Logs from each node will belong to the corresponding task, and each task’s state is determined by the state of that node’s execution.
The task runs created by calling .invoke() run separately from dbt Core, and do not affect dbt’s execution behavior. These tasks do not persist results and cannot be cached.Use dbt’s native retry functionality in combination with runtime data from prefect to retry failed nodes.

Assets

Prefect Cloud maintains a graph of assets, objects produced by your workflows. Any dbt seed, source or model will appear on your asset graph in Prefect Cloud once it has been executed using the PrefectDbtRunner. The upstream dependencies of an asset materialized by prefect-dbt are derived from the depends_on field in dbt’s manifest.json. The asset’s key will be its corresponding dbt resource’s relation_name. The name asset property is derived from the dbt resource’s relation_name with adapter-specific quoting characters removed (for example, "dev"."main_marts"."product_metrics" becomes dev.main_marts.product_metrics). The description property is populated from the dbt resource’s description. The owners asset property is populated if there is data assigned to the owner key under a resource’s meta config.
Asset metadata is collected from the result of the node’s execution.
Optionally, the compiled code of a dbt model can be appended to the asset description.

dbt settings

The PrefectDbtSettings class, based on Pydantic’s BaseSettings class, automatically detects DBT_-prefixed environment variables that have a direct effect on the PrefectDbtRunner class. If no environment variables are set, dbt’s defaults are used. Provide a PrefectDbtSettings instance to PrefectDbtRunner to customize dbt settings or override environment variables.

Logging

The PrefectDbtRunner class maps all dbt log levels to standard Python logging levels, so filtering for log levels like WARNING or ERROR in the Prefect UI applies to dbt’s logs. By default, the logging level used by dbt is Prefect’s logging level, which can be configured using the PREFECT_LOGGING_LEVEL Prefect setting. The dbt logging level can be set independently from Prefect’s by using the DBT_LOG_LEVEL environment variable, setting log_level in PrefectDbtSettings, or passing the --log-level flag or log_level kwarg to .invoke(). Only logging levels of higher severity (more restrictive) than Prefect’s logging level will have an effect.

profiles.yml templating

The PrefectDbtRunner class supports templating in your profiles.yml file, allowing you to reference Prefect blocks and variables that will be resolved at runtime. This enables you to store sensitive credentials securely using Prefect blocks, and configure different targets based on the Prefect workspace. For example, a Prefect variable called target can have a different value in development (dev) and production (prod) workspaces. This allows you to use the same profiles.yml file to automatically reference a local DuckDB instance in development and a Snowflake instance in production.

Failure handling

By default, any dbt node execution failures cause the entire dbt run to raise an exception with a message containing detailed information about the failure.
The PrefectDbtRunner’s raise_on_failure option can be set to False to prevent failures in dbt from causing the failure of the flow or task in which .invoke() is called.

Native dbt configuration

You can disable automatic asset lineage detection for all resources in your dbt project config, or for specific resources in their own config:

Lifecycle hooks

Lifecycle hooks are available in prefect-dbt 0.7.24 and later.
PrefectDbtRunner supports decorator-based lifecycle hooks that let you react to events during a dbt invocation. Hooks are registered on a runner instance and receive a DbtHookContext with information about the event.

Available hooks

When select= is provided, the hook only fires for nodes matching the given dbt selector. For on_run_end, a selector filters by the set of node IDs that participated in the run.

DbtHookContext fields

Each hook receives a DbtHookContext dataclass. The fields available depend on the hook event:

Error handling

Hooks are best-effort: if a hook raises an exception, Prefect logs a warning and dbt execution continues normally. Do not use hooks as failure-control mechanisms for dbt — use dbt’s own on-run-end hooks or Prefect automations for critical failure responses.
Hooks run synchronously in the runner’s process. Long-running hook logic delays dbt node processing and the on_run_end hook. Keep hooks lightweight — emit metrics, log information, or enqueue work rather than performing expensive operations inline.

Recipes

The examples below use placeholder functions (emit_metric, notify, etc.) for external systems — wire them up to your own metrics or notification client.

Emit a metric when a critical model fails

Combine post_model(select=...) with ctx.status to react to failures of important models without filtering inside the hook body. The selector uses dbt’s node selection syntax, so any tag, FQN, or graph operator your project uses will work.

Send a run summary after dbt completes

Use on_run_end to log or post a summary derived from ctx.run_results and ctx.status. The hook fires for both successful and failed runs.

Inspect run_results safely

ctx.run_results is None when dbt could not produce results (for example, a parse failure during compile), and individual entries may be missing fields depending on the dbt version. Use .get() with defaults rather than indexing.

Use select= with post_model and on_run_end

Both post_model and on_run_end accept dbt selectors. on_run_start does not — it always sees the full set of nodes scheduled for the run, and passing select= raises TypeError.
The selector is resolved against the project manifest once per invocation. If a selector does not match any node in the resolved manifest (or fails to resolve), the hook silently fires for nothing — check your selector with dbt ls --select <selector> if a hook isn’t running.

See also