dbt run error: relation does not exist

Not specified by the original author.

TL;DR

The warehouse cannot find the table or view your model points at, which almost always means the schema or database in the compiled SQL is not where you think it is. Print the compiled SQL from the target directory and check the fully qualified name against the warehouse. Nine times out of ten it is a target or custom schema mismatch, not a missing table.

dbt run error: relation does not exist

Use this when

• dbt run fails with relation does not exist on a ref or source.
• It works for one target but fails for another.
• A renamed model or schema recently changed.

Not for this skill when

• The error is permission denied. The relation exists; access is the problem.
• dbt cannot connect at all. That is a profile problem.

Steps

1. Open the compiled SQL in target/compiled for the failing model and copy the fully qualified relation name. Note the exact database, schema, and table. Verify: you see what dbt actually asked for
2. Check that qualified name directly in the warehouse. Note whether it exists. Verify: existence is verified, not assumed
3. Compare against your target, custom schema settings, and any generateschemaname macro overrides. Note which setting produced the wrong qualifier. Verify: the misconfiguration is found
4. Fix the schema config or the ref, then re-run dbt compile and confirm the qualifier is right. Note the compiled SQL now points at the real relation. Verify: the SQL targets reality
5. Re-run the model and confirm it builds. Note the run is green. Verify: the fix is verified

Variant phrasings

dbt relation does not exist ref

The ref-shaped phrasing.

dbt compiled sql wrong schema

The diagnosis-shaped search.

Compatibility: dbt Core 1.x, all warehouse adapters. Schema generation macros behave the same everywhere; quoting rules differ by adapter.

Why it happens

dbt builds the fully qualified name from several layers: the profile target, the model config schema, custom schema macros, and quoting rules. Any one of them can silently redirect the name somewhere the table was never created, especially when switching targets or when a macro override only applies in prod. The error message names the relation dbt looked for, which is the fastest clue: compare it with where the table actually lives and the gap is usually obvious.

Edge cases / pitfalls

• Case sensitivity differs by warehouse. An unquoted mixed-case name on Snowflake resolves uppercase and misses the table.
• Sources need explicit schema and database in sources.yml. A source defined without them resolves against the target defaults.
• A model that was renamed leaves the old table behind. The old table existing can mask that the new one was never built.
• generateschemaname macros that behave differently per target are a classic prod-only breakage. Test the macro under each target.

Provenance

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

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

Thread query: dbt run error: relation does not exist

TL;DR: The warehouse cannot find the table or view your model points at, which almost always means the schema or database in the compiled SQL is not where you think it is. Print the compiled SQL from the target directory and check the fully qualified name against the warehouse. Nine times out of ten it is a target or custom schema mismatch, not a missing table.

Not specified by the original author.

TL;DR

Something queried analytics.dim_customers and the warehouse says it is not there. Either the model was never built in this target, it was built into a different schema, or it was dropped. Rebuild the model with dbt run --select dim_customers, verify the schema in your profile target, and confirm the relation exists before rerunning downstream work.

Error

RelationNotFound: relation 'analytics.dim_customers' does not exist

Steps

1. Check whether the relation exists right now by querying your warehouse's information schema for dim_customers in schema analytics. Expected: you learn whether it is truly missing or just in the wrong schema.
2. Compare the schema against your profile target: the schema (and database) in profiles.yml for the active target must match where you are looking. Expected: the target schema equals analytics, or you adjust your expectation.
3. Rebuild the model: dbt run --select dim_customers. Expected: the run succeeds and the relation appears in the warehouse.
4. If a downstream model or a docs query triggered the error, rerun it now. Expected: the RelationNotFound error is gone.
5. If the relation keeps disappearing, check for a --full-refresh in a scheduled job or a drop step that removes it. Expected: you find the job responsible.

When to use

• A dbt run, test, or docs query fails with RelationNotFound.
• You switched targets (dev to prod) and relations seem missing.

When not to use

• dbt compile fails with a dependency error (the node is missing from the graph, not the warehouse).
• The relation exists but queries fail with permission errors (a grants problem).

Tool compatibility

• dbt Core 1.0 and later, all adapters. Information schema queries differ slightly per warehouse.

Variant phrasings

relation "analytics.dim_customers" does not exist

The Postgres-style quoting of the same error; the fix is identical.

RelationNotFound on a seed or snapshot

Seeds and snapshots are relations too; rebuild with dbt seed or dbt snapshot.

Why it happens

dbt renders relation names from the target's database and schema plus the model name. A mismatch between where dbt built the model and where the query looks, or a model that was never built in this environment, produces this error.

Edge cases

• Custom schemas via generate_schema_name change where models land; check the macro before assuming the default.
• On Snowflake, case matters: unquoted identifiers fold to uppercase.
• Cloned or time-traveled databases can hide recently built relations from the session that built them.

Provenance

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

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

Thread query: "RelationNotFound: relation 'analytics.dim_customers' does not exist"

TL;DR: Something queried analytics.dim_customers and the warehouse says it is not there. Either the model was never built in this target, it was built into a different schema, or it was dropped. Rebuild the model with dbt run --select dim_customers, verify the schema in your profile target, and confirm the relation exists before rerunning downstream work.

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.