## TL;DR

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

```text
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 analytics_stg.stg_orders 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 stg_orders is among them, then check target/manifest.json for the schema dbt assigned to stg_orders.
   Verify: manifest shows the database and schema dbt intends for stg_orders.

2. Query the warehouse information_schema for any schema containing a stg_orders 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 stg_orders first. If it landed in the wrong schema, inspect generate_schema_name in macros/ and the schema config for the staging folder in dbt_project.yml, and fix the duplication, for example a custom macro that appends the target schema twice.
   Verify: dbt run --select stg_orders creates analytics_stg.stg_orders, confirmed by an information_schema 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 generate_schema_name 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