dbt run succeeds but the snowflake table is empty

Not specified by the original author.

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

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

Thread query: 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.

Not specified by the original author.

TL;DR

Create the staging relation before the test run, in the right schema: the test queried a staging table that the run never built, usually because the test ran standalone, the model was deselected, or the schema macro resolves differently under the test target. A test cannot create its model. Running dbt test alone against a target where the staging model was never materialised produces exactly this database error.

how to fix dbt error "database error: relation staging table does not exist" during test run

Use this when

• The check or run fails with this symptom: a dbt run fails with database error relation staging table does not exist during a test run.
• You are working on a dbt project running tests against a target where the staging model may not have been built and the failure repeats on the same data or configuration.
• You need the failing rows, rule, or stage isolated before changing thresholds or code.

Not for this skill when

• A production incident where the staging table was dropped by another process, which needs ownership and permissions work rather than a build order fix.
• The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Check whether the staging relation exists in the target schema the test ran against. Verify: the relation is absent in that schema, or present under a different schema name
2. Review the command that ran: a test-only invocation, a selection that excluded the model, or a fresh target. Verify: the reason the model was never built is identified
3. Run dbt build or dbt run for the staging model and its parents in the same target. Verify: the relation exists with current data
4. Rerun the tests in the same invocation pattern the pipeline uses. Verify: tests pass against the built relation
5. Make the pipeline entry point a build or a run-then-test sequence so the standalone test case cannot recur. Verify: the job definition shows the ordered steps

Variant phrasings

dbt database error relation staging table does not exist test

The shorter phrasing focused on the named failure.

dbt test relation does not exist staging

The symptom phrasing a searcher tries next.

dbt staging table missing during test run fix

The variant naming the failing stage or tool directly.

Compatibility: dbt Core 1.5 and later, dbt build and test selection behaviour

Why it happens

Relation existence depends on target, schema macros, and what ran before. Ephemeral models, custom schema names, and test-only CI steps against empty schemas all produce a missing relation that looks like a data problem but is a build order problem.

Edge cases / pitfalls

• Custom generateschemaname macros often resolve differently for the default target and CI targets; compare the compiled relation name across targets.
• An ephemeral model has no relation at all; a test or a downstream query that expects a physical table needs the materialisation changed.

Provenance

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

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

Thread query: how to fix dbt error "database error: relation staging table does not exist" during test run

TL;DR: Create the staging relation before the test run, in the right schema: the test queried a staging table that the run never built, usually because the test ran standalone, the model was deselected, or the schema macro resolves differently under the test target. A test cannot create its model. Running dbt test alone against a target where the staging model was never materialised produces exactly this database error.

Not specified by the original author.

TL;DR

An empty catalog means the adapter's metadata query returned nothing: usually the target points at the wrong database or schema, or the role cannot read the information schema. Run dbt debug, fix the target or the grants, regenerate, and serve.

Error

dbt docs generate failed: empty catalog.json produced

Steps

1. Run dbt debug and confirm the target database and schema. Expected: they match where your relations actually live.
2. Check that relations exist in that database and schema by listing them in the warehouse. Expected: you see your models, seeds, and snapshots there.
3. Verify the dbt role can read the warehouse metadata (information schema or equivalent). Expected: a metadata query as that role returns rows.
4. Run dbt docs generate again. Expected: catalog.json is now populated.
5. Run dbt docs serve and open the site. Expected: models show column-level catalog data.

When to use

• dbt docs generate finishes but catalog.json is empty or nearly empty.
• Docs show models but no columns.

When not to use

• dbt docs generate crashes (an artifact or version problem).
• The docs site is missing models entirely (a manifest problem).

Tool compatibility

• dbt Core 1.0 and later, all adapters. Catalog queries are adapter-specific under the hood.

Variant phrasings

catalog.json has sources but no models

The target schema for models differs from where docs generate looked.

Docs columns missing after a warehouse migration

The new warehouse needs the metadata grants re-applied.

Why it happens

Docs generation queries the warehouse for table and column metadata using the active target. A target pointing at an empty database, or a role blocked from metadata, yields an empty catalog without erroring.

Edge cases

• On BigQuery, the catalog query needs dataset metadata permissions, not just data access.
• Very large warehouses can time out the catalog query; generate against a smaller target or increase timeouts.
• dbt docs generate uses the manifest from the last compile; recompile first if the manifest is stale.

Provenance

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

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

Thread query: dbt docs generate failed: empty catalog.json produced

TL;DR: An empty catalog means the adapter's metadata query returned nothing: usually the target points at the wrong database or schema, or the role cannot read the information schema. Run dbt debug, fix the target or the grants, regenerate, and serve.