dbt run succeeds but the snowflake table is empty

TL;DR

The run succeeded because the SQL ran, but its predicates or joins filtered out every row: common culprits are an incremental filter against the wrong max timestamp, a var or target-dependent filter, or an inner join to an empty upstream. Compile the model, run its SQL manually in Snowflake with filters relaxed step by step, and fix the predicate that eats all rows.

dbt run succeeds but the snowflake table is empty

Use this when

• dbt run reports success but select count from the Snowflake table returns 0
• the source tables visibly contain matching data
• the problem started after adding an incremental filter, a join, or an environment-specific var

Not for this skill when

• the table is a view on an empty upstream, fix the upstream data load
• zero rows is correct for the period (new table, no data yet), confirm with the data owner before changing SQL
• the run actually targeted a different schema and you are querying the wrong table copy

Steps

1. Confirm identity first: check the run target schema and database in the logs, and count rows in the exact relation dbt built, plus counts of each direct upstream. Verify: you know the built relation is empty while upstreams are not (or you found you were querying the wrong copy).

2. Open target/compiled SQL for the model and run it in Snowflake as a select, without the incremental wrapper. If it returns rows, the incremental logic is at fault; if not, bisect the where clauses and joins by removing one at a time. Verify: you have isolated the clause or join that drops all rows.

3. Fix the culprit: for incremental models, correct the watermark comparison (for example comparing a timestamp column to max of the same column with timezone or truncation mismatch), for var filters set the var for this target, for joins consider left join if the side table is optional. Verify: the compiled select returns the expected row count in Snowflake.

4. Rerun dbt run --select for the model (with --full-refresh if incremental state is poisoned) and recount the table. Verify: the table holds the expected rows and a second incremental run adds only new rows.

Variant phrasings

empty only in prod

Target-dependent code (target.name checks, prod-only vars, prod schemas with no data yet) explains most environment splits. Diff compiled SQL between dev and prod targets.

empty after first incremental run

A watermark initialized from an empty target can lock the model at zero. Full refresh once with corrected logic, then resume incremental runs.

Compatibility: dbt-core models on Snowflake; compiled SQL under target/compiled. The same bisection method works on other adapters, but timezone and timestamp semantics are Snowflake specific here.

Why it happens

dbt success only means the statements executed, not that they matched data. A filter comparing timestamps across timezones, an equality join on keys with different casing or padding, or an incremental predicate anchored to a max that is already ahead of the source will all legitimately produce zero rows with no error anywhere.

Edge cases / pitfalls

• Snowflake string comparisons and join keys are sensitive to case and trailing spaces from some loaders; profile the join keys, do not assume.
• An empty table that downstream models join against propagates emptiness silently; add a row-count test or an accepted range check on critical models.
• Check dbt run_results and the Snowflake query history to confirm the merge or insert statement actually ran against the schema you are inspecting.

Provenance

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