Database Error: permission denied for table on dbt run
Fixes warehouse permission errors during dbt runs for analytics engineers and repair agents. Use when dbt run fails with permission denied on a table or schema. Not for connection failures or missing relations.
TL;DR
The role dbt connects as lacks a grant on the table or schema. Find which role your profile uses, then have someone with grant rights run the missing GRANT (usually USAGE on the schema plus SELECT on the table). Re-run dbt debug first so you are fixing the right role.
Error
Database Error: permission denied for table on dbt runSteps
Run dbt debug and note the exact role or user the profile connects as. Then check the failing SQL in logs/dbt.log to see the table and the operation (select, insert, create). Expected: You know the role, the table, and whether it was a read or a write that got denied.
Connect as an admin role and inspect current grants: on Snowflake SHOW GRANTS TO ROLE therole; on Postgres check informationschema.roletablegrants; on BigQuery check IAM on the dataset. Expected: You see the missing grant explicitly, e.g. no USAGE on the schema or no SELECT on the table.
Grant the minimum needed: USAGE on the schema, then SELECT (for reads) or the write privileges dbt needs (CREATE TABLE, INSERT) for the target schema. Expected: The grant statements succeed.
Re-run the failed dbt command. If it still fails, check whether future grants are needed for tables created later (Snowflake future grants, Postgres default privileges). Expected: dbt run passes; new tables created by dbt are readable by downstream roles.
When to use
- dbt run fails with permission denied for table or schema
- works in dev but fails in prod (different roles per target)
- a new source table was added that the dbt role was never granted on
When not to use
- relation does not exist (that is a missing object, not a grant)
- connection refused or authentication failed (that is before any permission check)
- the error is on a dbt Cloud job with a different service account than local
Tool compatibility
- Snowflake, Postgres, Redshift, BigQuery: grant syntax differs, concept is the same
- dbt debug confirms the active role per target
- dbt Cloud: check the deployment environment's credentials, they may differ from yours
Variant phrasings
permission denied for schema
Missing USAGE on the schema. Grant it before table-level grants; without schema USAGE, table grants do nothing.
permission denied for relation on a seed
Seeds create tables, so the role needs CREATE on the target schema, not just SELECT.
Why it happens
dbt runs as a single role per target, and warehouses deny by default. Dev often works because your personal user has broad rights while the CI or prod role is locked down. New tables also need future or default grants or the next created table fails the same way.
Edge cases
- On Snowflake, ownership transfers and cloned databases reset grants; re-apply future grants after a clone.
- BigQuery dataset-level IAM covers new tables automatically, but table-level ACLs do not.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_ciRXDxc2W5ZkAqnKT9sGXw