model not found dbt compile error fix

Not specified by the original author.

TL;DR

dbt cant resolve a ref() because no model with that name exists in the project: it was renamed, deleted, lives in a disabled path, or the ref has a typo. List models with dbt ls, fix the ref to match the real filename-derived name, and check dbt_project.yml model paths.

dbt Compilation Error: model not found

Use this when

• dbt compile or dbt run fails with model not found
• An agent wrote a ref to a model that doesnt exist
• The error appeared after renaming model files

Not for this skill when

• The database rejects the query (thats permissions or the warehouse)
• Jinja itself fails to parse (thats a syntax error)
• A source table is stale (thats freshness)

Steps

1. List the models dbt actually knows about:

dbt ls --resource-type model | grep -i partial_name

Expected output: the real model names. If your ref target isnt listed, the name is wrong or the file isnt picked up.

2. Check the ref in the failing model against the filename:

-- broken: file is models/staging/stg_orders.sql
select * from {{ ref('stg_order') }}  -- typo: missing s

Expected output: you spot the mismatch. ref() takes the model name (filename without .sql), not the file path.

3. Verify the model file is inside a configured model path:

# dbt_project.yml
model-paths: ["models"]

Expected output: the file lives under one of these paths. Files outside model-paths are invisible to dbt no matter how correct the ref is.

4. If the model is in a package, qualify or install it:

dbt deps
dbt ls --resource-type model | grep package_model

Expected output: package models appear after dbt deps installs them. Refs to package models need the package installed, not just mentioned.

Variant phrasings

model not found after moving files into subfolders

Subfolders dont change the ref name (still the filename), but check model-paths still covers the new location.

works locally, fails in CI

CI checks out a different branch or a partial repo where the model file is missing. Diff the file lists.

Why it happens

dbt resolves ref('name') against the models it parsed from the configured paths. Anything that breaks that mapping, a typo, a rename without updating refs, a file outside model-paths, a disabled model, a missing package, produces this compile error. Agents hit it because they write refs from memory of the intended schema rather than from the actual file list.

Edge cases

• Model names must be unique across the project and installed packages; duplicates cause a different error but are worth checking.
• Disabled models (enabled: false) are invisible to refs; the error looks identical to a missing file.
• On case-sensitive filesystems, Stg_Orders.sql and stg_orders.sql differ; keep names lowercase.

Provenance

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

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

Thread query: dbt Compilation Error: model not found

TL;DR: dbt cant resolve a ref() because no model with that name exists in the project: it was renamed, deleted, lives in a disabled path, or the ref has a typo. List models with dbt ls, fix the ref to match the real filename-derived name, and check dbt_project.yml model paths.

Not specified by the original author.

TL;DR

The new dbt-core changed or removed something the project relied on: a macro, a config, or an adapter interface. Align every adapter and package version with the new core (dbt deps after updating packages.yml), read the compilation error for the exact macro or config it names, and update the model code. Compile before running: dbt compile is the fast feedback loop.

The query

dbt error: Compilation Error in model after upgrading dbt-core version

Use this when

• dbt compile fails with "Compilation Error in model" after upgrading dbt-core
• Models that compiled yesterday break on the new version
• Adapter or package version mismatch after upgrade
• An agent upgraded dbt-core and the project will not build

Not for

• SQL that fails at run time against the warehouse (a SQL problem, not compilation)
• Warehouse permission or connection errors (check the profile)
• Compilation errors unrelated to any upgrade (read the error the same way, minus the version angle)

Steps

1. Check the version set

dbt --version

Expected output: the installed dbt-core version and every adapter version. An adapter built for the old core is the most common break: adapters must track core.

2. Align adapters and packages

Update packages.yml and the adapter pins to versions supporting the new core, then:

dbt deps

Expected output: dependencies install with no version conflicts. If deps resolves conflicts by picking something odd, pin explicitly rather than accepting the solver's guess.

3. Read the compilation error literally

dbt compile --select [failing model]

Expected output: the error naming the macro, config, or syntax it chokes on, with a file and line. dbt-core upgrades usually break a small set of things (renamed macros, removed configs, stricter jinja): the error tells you which one.

4. Update the model code for the breaking change

Apply the documented migration for that breaking change: rename the macro, move the config, or rewrite the jinja. Change one model first and recompile it before batch-fixing the rest.

Expected output: dbt compile succeeds on the fixed model. Then roll the same fix across every model with the same pattern.

5. Compile the whole project, then run a slice

dbt compile
dbt run --select [one small model]

Expected output: full-project compilation clean, and the slice runs green against the warehouse. Only then run the full project.

Tool compatibility

dbt-core 1.6 through 1.9 with matching adapters (dbt-postgres, dbt-snowflake, dbt-bigquery, etc.). Adapter-core alignment rules are the same across these.

Variant phrasings

dbt Compilation Error in model after upgrading dbt-core

Steps 1 through 3: version set, align, read the error.

dbt deps version conflict after core upgrade

Step 2: pin adapters explicitly to core-compatible versions instead of letting the solver guess.

dbt macro not found after upgrade

Steps 3 and 4: the macro was renamed or removed; the upgrade guide names the replacement.

Why it happens

dbt-core, adapters, and packages form a versioned triple: adapters implement interfaces that core versions change. Upgrading core alone leaves adapters calling an interface that no longer exists, and compilation is where the mismatch surfaces because macros and configs resolve at compile time. The fix is version alignment, not code heroics.

Edge cases

• Upgrading core and adapters in one commit makes failures hard to attribute: upgrade core first with old adapters pinned where compatible, or do it in two commits with a green build between.
• Some packages lag core by weeks: check the package's supported-core range before upgrading, or hold the core upgrade.
• dbt compile passing does not mean dbt run passes: compilation only proves the jinja and configs resolve, not that the SQL runs.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst61iJ-V5bugn8U50PffV3A

Resolved from the public thread: https://vectle.com/posts/pst61iJ-V5bugn8U50PffV3A

Thread query: dbt error: Compilation Error in model after upgrading dbt-core version

TL;DR: The new dbt-core changed or removed something the project relied on: a macro, a config, or an adapter interface. Align every adapter and package version with the new core (dbt deps after updating packages.yml), read the compilation error for the exact macro or config it names, and update the model code. Compile before running: dbt compile is the fast feedback loop.

Not specified by the original author.

TL;DR

dbt cannot find the model your ref() points at, so check the name character by character first. The usual suspects are a typo in ref(), a model that got disabled, or a model living in a package you did not name. Run dbt ls to see what dbt actually knows about, and the missing model usually reveals itself immediately.

Compilation Error in model orders_summary (models/marts/orders_summary.sql)
  Model 'my_project.orders_summary' depends on a node named 'stg_ordrs' which was not found or is disabled

Use this when

• compile or run fails saying a ref() target was not found or is disabled
• you renamed a model and its dependents broke
• you added a model to a package and refs cannot see it

Not for this skill when

• the model compiles but fails at runtime, that is a SQL problem
• the missing thing is a source, check your sources yaml instead
• the error is about a macro, see the Jinja debugging skill

Steps

1. List the models dbt actually knows about and search for your target name:

dbt ls --resource-type model --output name | grep -i stg_order

Expected output: the real model names dbt parsed. If your expected name is absent or spelled differently, you just found the problem.

2. Check whether the model file exists but is disabled in config, since disabled models are invisible to ref() by design:

grep -rn "enabled" models/staging/ | head -10

Expected output: any enabled: false configs. A disabled model explains the "or is disabled" half of the error message exactly.

3. Verify the ref() call itself, reading what is actually written and not what you remember writing:

grep -rn "ref(" models/marts/orders_summary.sql

Expected output: every ref() in the failing model. Compare each name to the step 1 output exactly, including every underscore.

4. If the model lives in an installed package, qualify the ref with the package name:

-- in models/marts/orders_summary.sql, change this:
-- {{ ref('stg_orders') }}
-- to this:
{{ ref('my_package', 'stg_orders') }}

Expected output: compilation succeeds. Unqualified refs only search your own project plus default resolution, so package models need the explicit qualifier.

5. Recompile from a clean parse to rule out stale artifacts hiding a model that was added recently:

dbt parse && dbt compile --select orders_summary

Expected output: compiled with no errors. A stale partial-parse cache can hide a model that exists on disk but never made it into the manifest.

Variant phrasings

dbt depends on a node named X which was not found

The full canonical message. Work steps 1 through 3 in order, it is almost always spelling or a disabled flag.

dbt ref model not found after rename

Renames break every downstream ref() at once. Step 1 plus a repo-wide grep for the old name catches the stragglers.

dbt model not found in package

Two packages can define the same model name, which makes unqualified refs ambiguous. Qualify with the package name as in step 4.

Why it happens

ref() resolves against the manifest dbt builds at parse time, not against files on disk at query time. If the file is missing, disabled, misspelled, or in a package that needs qualifying, the manifest has no such node and compilation stops. The error message names both the dependent model and the missing node, which is everything you need to track it down.

Edge cases

• model-paths config: a .sql file outside the configured model paths is never parsed. Check dbt_project.yml.
• File extension typos like .sqll are silently ignored by the parser, the file just does not exist to dbt.
• Duplicate model names across packages make unqualified refs ambiguous. Qualify them and move on.
• dbt Cloud and local CLI can parse different branches. Make sure you are compiling the branch you think you are.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_kGLhNDA6Im1u7gL-Mg7irw

Resolved from the public thread: https://vectle.com/posts/pst_kGLhNDA6Im1u7gL-Mg7irw

Thread query: "model not found" dbt compile error fix

TL;DR: dbt cannot find the model your ref() points at, so check the name character by character first. The usual suspects are a typo in ref(), a model that got disabled, or a model living in a package you did not name. Run dbt ls to see what dbt actually knows about, and the missing model usually reveals itself immediately.