Database Error in model: relation 'analytics_stg.stg_orders' does not exist

Not specified by the original author.

TL;DR

The model selected from analyticsstg.stgorders, a schema plus relation that does not exist. Usually the staging model was never run, was built into a different schema, or a custom generateschemaname macro produced an unexpected schema. Build the upstream staging model into the schema the downstream model expects, or fix the schema macro, then rerun.

Database Error in model: relation 'analytics_stg.stg_orders' does not exist

Use this when

• dbt run fails with Database Error in model and relation analyticsstg.stgorders does not exist
• the missing relation is itself a dbt model in the same project
• the schema part looks doubled, prefixed, or different between dev and prod

Not for this skill when

• the missing relation is a raw source, load it with your ingestion tool instead of dbt run
• the model was intentionally deleted, remove the downstream ref instead
• the error is permission denied rather than does not exist

Steps

1. Run dbt ls --select + on the failing model to list its upstream nodes and confirm stgorders is among them, then check target/manifest.json for the schema dbt assigned to stgorders. Verify: manifest shows the database and schema dbt intends for stg_orders.

2. Query the warehouse informationschema for any schema containing a stgorders table or view. Compare what you find with the manifest value. Verify: you know whether stg_orders is missing entirely or built under a different schema name.

3. If it is missing, run dbt run --select stgorders first. If it landed in the wrong schema, inspect generateschemaname in macros/ and the schema config for the staging folder in dbtproject.yml, and fix the duplication, for example a custom macro that appends the target schema twice. Verify: dbt run --select stgorders creates analyticsstg.stgorders, confirmed by an informationschema query.

4. Rerun the original failing model with dbt run --select and its downstream consumers. Verify: the run succeeds with no does not exist error.

Variant phrasings

works in dev, missing in prod

Dev targets often append the developer name to schemas. Check that the prod target and the schema macro agree, and that the prod job actually includes the staging layer.

missing after a rename

Renaming the staging model or its folder changes the generated schema. Update folder schema config and rebuild the staging layer.

Compatibility: dbt-core 1.3 and later on Postgres, Snowflake, BigQuery, and Redshift; schema naming depends on your generateschemaname macro and dbt_project.yml folder config.

Why it happens

dbt does not create a downstream model dependency out of thin air: the compiled SQL contains the fully qualified relation from the manifest. If the upstream build never ran in that target, or schema generation produced a different name than the downstream ref resolved to, the warehouse correctly reports that the relation does not exist.

Edge cases / pitfalls

• An ephemeral staging model has no warehouse relation at all; downstream models inline it, so a does not exist error means something forced a direct reference.
• Partial runs with --select that exclude staging will keep failing until staging is built once in that target.
• Case and quoting differ by adapter; an unquoted uppercase name on Snowflake can look like a missing relation.

Provenance

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

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

Thread query: Database Error in model: relation 'analyticsstg.stgorders' does not exist

TL;DR: The model selected from analyticsstg.stgorders, a schema plus relation that does not exist. Usually the staging model was never run, was built into a different schema, or a custom generateschemaname macro produced an unexpected schema. Build the upstream staging model into the schema the downstream model expects, or fix the schema macro, then rerun.

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

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.