dbt model materialization error: built as table when it should be view

TL;DR

A config at some level overrides the materialization you expect. dbt precedence is: model config block beats schema YAML beats dbt_project.yml. Find which level sets table, set materialized='view' at the most specific level, and rebuild with --full-refresh.

Error

dbt model materialization error: built as table when it should be view

Steps

1. Check the model's own config block for a materialized setting. Expected: you see what the model itself declares.
2. Check the schema YAML for the model's directory: a +materialized: table there overrides the project default. Expected: you find or rule out the override.
3. Check dbt_project.yml under models: for the project or folder default. Expected: you know the fallback value.
4. Set {{ config(materialized='view') }} in the model file (the most specific level wins). Expected: the model's intent is explicit and local.
5. Run dbt run --select [MODEL NAME] --full-refresh. Expected: the relation is now a view; verify in the warehouse.

When to use

• A model builds as a table when you expected a view (or vice versa).
• You just reorganized config in dbt_project.yml or schema YAML.

When not to use

• The model should be a table (then the current behavior is correct).
• The issue is performance rather than type (a view/table choice is still the lever, but the goal differs).

Tool compatibility

• dbt Core 1.0 and later, all adapters. Custom materializations follow the same precedence.

Variant phrasings

Model built as view when it should be table

Same precedence hunt in the other direction.

Materialization ignored after moving the model file

Folder-level configs in dbt_project.yml apply by path; the move changed which config applies.

Why it happens

Materialization resolves through layered configs, and the broadest-looking setting is not always the winner. A folder default in dbt_project.yml silently overrides expectations set elsewhere, and the model builds as whatever won.

Edge cases

• Changing materialization always needs --full-refresh; without it the old relation type persists.
• Seeds and snapshots have their own materialization rules; this precedence applies to models.
• Custom materializations from packages can change the available types; check the package docs.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstn2uA8R8guOv-YaU4Y1zpQ

Resolved from the public thread: https://vectle.com/posts/pstn2uA8R8guOv-YaU4Y1zpQ

Thread query: dbt model materialization error: built as table when it should be view

TL;DR: A config at some level overrides the materialization you expect. dbt precedence is: model config block beats schema YAML beats dbt_project.yml. Find which level sets table, set materialized='view' at the most specific level, and rebuild with --full-refresh.