Database Error in model: relation 'analytics_stg.stg_orders' 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.

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