Database Error: canceling statement due to statement timeout in dbt

TL;DR

The warehouse killed your query for running too long. Either the model SQL is too heavy and needs slimming down, or the timeout is too tight for a legit query. Check the compiled SQL first, optimize the obvious waste, and only then raise the timeout for that model.

Error

Database Error: canceling statement due to statement timeout in dbt

Steps

1. Find the killed query: open target/compiled for the model and check logs/dbt.log for how long it ran before cancellation. Expected: You have the exact SQL and its runtime, e.g. killed at 300s on a 6-way join.

2. Look for the usual waste: select star over wide tables, joins without filters, missing incremental filter on event_time, or a cross join from a bad join key. Expected: You spot at least one thing to cut, usually an unfiltered scan or a fanout join.

3. Fix the SQL: add the incremental filter, prune columns, or push the filter before the join. Re-run and time it. Expected: Runtime drops well under the timeout.

4. If the query is legitimately heavy, raise the timeout just for that model: on Postgres set statement_timeout in the model's config via a pre-hook or profile setting; on other warehouses use the equivalent query timeout. Expected: The model completes; other models keep the stricter timeout.

When to use

• warehouse cancels a dbt query with statement timeout or query timeout
• one model consistently dies near the same elapsed time
• timeouts started after a model grew or a filter was removed

When not to use

• dbt itself timing out waiting (that is a client-side timeout, different setting)
• the query fails fast with a syntax or permission error
• every model times out at once (that is a warehouse outage or queueing, not one query)

Tool compatibility

• Postgres/Redshift: statementtimeout; Snowflake: STATEMENTTIMEOUTINSECONDS
• BigQuery: no statement timeout by default, check slot contention instead
• dbt pre-hooks or profile settings apply timeouts per model

Variant phrasings

canceling statement due to lock timeout

Different cause: waiting on a lock, not slow execution. See the deadlock skill, check for blocking sessions.

timeout only in dbt Cloud

dbt Cloud jobs can have their own run timeouts on top of warehouse ones. Check both; the warehouse message names the warehouse setting.

Why it happens

Warehouses cap runaway queries with a statement timeout. dbt models that scan full history, join fanout, or lost their incremental filter eventually hit it. The timeout is doing its job; the query changed, not the setting.

Edge cases

• Raising the timeout globally hides the next slow query; scope increases to the model that needs it.
• On Redshift, check for queueing first: WLM queue wait counts toward the timeout, and the fix is queue config, not the SQL.

Provenance

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