## 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.

```text
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 generate_schema_name 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.
- generate_schema_name 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