Database Error in model: permission denied for schema" dbt

TL;DR

The database role dbt connects with lacks privileges on the target schema. Grant USAGE and CREATE on the schema to that role (and future-table grants where your warehouse needs them), then rerun the model.

Error

"Database Error in model: permission denied for schema" dbt

Steps

1. Identify the role dbt connects as: check the role or user in the active profiles.yml target. Expected: you know the exact role name.
2. Check what the role can do: query the warehouse for the role's grants on the target schema. Expected: you confirm USAGE or CREATE is missing.
3. Grant the missing privileges, for example on Postgres: GRANT USAGE, CREATE ON SCHEMA analytics TO [ROLE];. Expected: the grant succeeds.
4. On Snowflake, also grant on future tables in the schema so dbt-created tables are usable: GRANT SELECT ON FUTURE TABLES IN SCHEMA analytics.[SCHEMA] TO [ROLE];. Expected: future tables inherit access.
5. Rerun dbt run --select [MODEL NAME]. Expected: the model builds without a permission error.

When to use

• dbt run fails with "permission denied for schema".
• You just added a new target schema or a new database role.

When not to use

• The denial names a specific table (grant on the table, not the schema).
• The connection itself fails (a credentials or network problem, not a grants problem).

Tool compatibility

• dbt Core 1.0 and later. Grant syntax is warehouse-specific; the examples above cover Postgres and Snowflake patterns.

Variant phrasings

permission denied for database / for relation

Sibling errors: the role lacks rights on the database or on one table; grant at the right level.

dbt grants config not applying

If you use dbt's grants config, the running role must own the object or hold grant privileges itself.

Why it happens

Warehouses deny by default. A new schema, a new role, or a rebuilt warehouse leaves dbt's role without the privileges its models need, and the first write to the schema fails.

Edge cases

• dbt's grants config only works if the running role can itself grant; otherwise the config silently does nothing useful.
• On BigQuery, the equivalent is dataset-level IAM roles, not SQL grants.
• Personal dev schemas often work while shared prod schemas fail; compare the two roles' grants.

Provenance

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