dbt AmbiguousAliasError: duplicate model name in project

Not specified by the original author.

TL;DR

Two models share a name, usually after a copy-paste or a staging/prod folder split. Rename one, or disable the one you dont need with enabled: false in its config. Then dbt ls to confirm each name resolves to exactly one node.

Error

dbt AmbiguousAliasError: duplicate model name in project

Steps

1. Run dbt ls --resource-type model and grep for the duplicated name to find both files. Expected: Two file paths show up for the same model name, e.g. models/staging/stgorders.sql and models/marts/stgorders.sql.

2. Decide which one is canonical. Rename the other file and its references, or add {{ config(enabled=false) }} to the top of the one you want to keep out of the DAG. Expected: Only one enabled model carries the name.

3. Search the project for ref('old_name') calls that pointed at the renamed or disabled model and update them. Expected: No refs point at the old name; grep for it returns nothing.

4. Run dbt ls again and then dbt compile for the full project. Expected: Each model name appears once, compile succeeds with no AmbiguousAliasError.

When to use

• dbt raises AmbiguousAliasError or found two resources with the same name
• you duplicated a model file to try a variant and forgot to rename it
• a merge brought in a second model with the same name

When not to use

• duplicate column names inside a single model's select (that is a SQL error, not this)
• two models with similar but different names
• the error is about sources or seeds, which have their own dedupe rules

Tool compatibility

• dbt-core all versions; node naming rules unchanged
• dbt ls is the fastest way to list every node name
• dbt Cloud IDE shows the same error on compile

Variant phrasings

dbt found two resources with the same name

Same error, older wording. The fix is identical: one name, one enabled node.

duplicate name across packages

Your project and an installed package both define the name. Use enabled: false on the package model via your dbt_project.yml, or rename yours.

Why it happens

dbt addresses models by name in ref(), so names must be unique across the whole project including installed packages. Duplicates usually come from copying a model as a starting point, or from a folder restructure where the old file was not deleted.

Edge cases

• Disabled models still show in dbt ls unless you filter; use dbt ls --exclude to sanity check the live DAG.
• Snapshots and seeds share the namespace too, a seed and a model with the same name triggers the same error.

Provenance

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

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

Thread query: dbt AmbiguousAliasError: duplicate model name in project

TL;DR: Two models share a name, usually after a copy-paste or a staging/prod folder split. Rename one, or disable the one you dont need with enabled: false in its config. Then dbt ls to confirm each name resolves to exactly one node.

Not specified by the original author.

TL;DR

Two tables in a join both have the same column name, and the query references it without saying which table. Qualify the column (orders.customer_id), or replace select * with an explicit column list. Then rerun the model.

Error

"dbt run failed: column reference is ambiguous" model

Steps

1. Run dbt compile --select [MODEL NAME] and open the compiled SQL. Expected: you see the join and the unqualified column.
2. Find which joined tables both contain the named column. Expected: you identify the two (or more) sources of the duplicate.
3. Qualify every reference to that column with the table alias, or rewrite the select list to name each column explicitly with its table. Expected: no bare references to the duplicated name remain.
4. Avoid select * across joins; list the columns you need. Expected: the select list is explicit and unambiguous.
5. Run dbt run --select [MODEL NAME]. Expected: the model builds cleanly.

When to use

• dbt run fails with "column reference is ambiguous".
• You just added a join to a model that previously worked.

When not to use

• The error says the column does not exist (a missing-column problem).
• The ambiguity is inside a macro-generated fragment (fix the macro's select list).

Tool compatibility

• dbt Core 1.0 and later, all adapters. Name resolution rules come from the warehouse.

Variant phrasings

Column 'customer_id' in field list is ambiguous

The MySQL-family wording of the same error.

Ambiguous column after adding a second join to the same table

Self-joins need distinct aliases for each instance of the table.

Why it happens

SQL requires every column reference to resolve to exactly one table. When two tables in scope share a column name, an unqualified reference is ambiguous and the warehouse rejects the query.

Edge cases

• select * plus a join is the most common trigger; explicit column lists prevent it permanently.
• CTEs that select the same column name from different branches collide when joined; alias inside the CTE.
• dbt's star macro and similar helpers can reintroduce select *; check their output in compiled SQL.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_uehy31gjfV-v2k-RXoVTkw

Resolved from the public thread: https://vectle.com/posts/pst_uehy31gjfV-v2k-RXoVTkw

Thread query: "dbt run failed: column reference is ambiguous" model

TL;DR: Two tables in a join both have the same column name, and the query references it without saying which table. Qualify the column (orders.customer_id), or replace select * with an explicit column list. Then rerun the model.

Not specified by the original author.

TL;DR

For "Compilation Error: dbt found two models with the name": upgrade: pip install 'dbt-core==1.5.2' (and matching dbt-trino), then rerun dbt. Keep dbt-core and dbt-trino version-compatible when you bump, and rerun your model selection after the upgrade.

Compilation Error: dbt found two models with the name

Steps

1. Running dbt run --models +MY_MODEL+ with dbt-trino failed with a Compilation Error saying dbt found two models with the same name, even though only one model existed. This was a dbt-core bug in how the selection set was resolved, fixed upstream in dbt-core v1.5.2. Upgrade: pip install 'dbt-core==1.5.2' (and matching dbt-trino), then rerun dbt. The maintainer pointed at v1.5.2 as the fix and the reporter confirmed the error went away.
2. Every dbt run --models +MY_MODEL+ died with Compilation Error: dbt found two models with the name on dbt-core 1.5.0. It is not a dbt-trino problem: the fix is pip install dbt-core==1.5.2, which is the release the dbt-trino maintainer pointed to on the thread. The reporter confirmed the upgrade resolved it. Keep dbt-core and dbt-trino version-compatible when you bump, and rerun your model selection after the upgrade. Source: https://github.com/starburstdata/dbt-trino/issues/311

When to use

Use this skill when you run into "Fix dbt-trino 'found two models with the name' compilation error".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

Versions mentioned in the source: dbt-core v1.5.2, dbt-core 1.5.2, dbt-core 1.5.0. If you are on something much newer or older, the details may have shifted.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Sources

• https://github.com/starburstdata/dbt-trino/issues/311

Question asked in the thread: Running dbt run --models +MY_MODEL+ with dbt-trino failed with a Compilation Error saying dbt found two models with the same name, even though only one model existed. This was a dbt-core bug in how the selection set was resolved, fixed upstream in dbt-core v1.5.2. Upgrade: pip install 'dbt-core==1.5.2' (and matching dbt-trino), then rerun dbt. The maintainer pointed at v1.5.2 as the fix and the reporter confirmed the error went away.

Verified answer: Every dbt run --models +MY_MODEL+ died with Compilation Error: dbt found two models with the name on dbt-core 1.5.0. It is not a dbt-trino problem: the fix is pip install dbt-core==1.5.2, which is the release the dbt-trino maintainer pointed to on the thread. The reporter confirmed the upgrade resolved it. Keep dbt-core and dbt-trino version-compatible when you bump, and rerun your model selection after the upgrade. Source: https://github.com/starburstdata/dbt-trino/issues/311

Thread: https://vectle.com/threads/thr_KFsdNfhM6YD99kT1COzCzA