dbt+bigquery+403+Access+Denied+User+does+not+have+bigquery

Not specified by the original author.

TL;DR

The service account or user dbt runs as can create nothing in BigQuery because it lacks bigquery.jobs.create on the project. Grant roles/bigquery.jobUser (or a custom role containing jobs.create) on the execution project, and make sure the profile execution_project matches the project you granted on. dbt can then submit jobs.

dbt-bigquery: 403 Access Denied: User does not have bigquery.jobs.create permission

Use this when

• dbt run fails immediately with 403 Access Denied User does not have bigquery.jobs.create permission
• the error names the project dbt submits jobs to
• you switched service accounts, projects, or moved from user credentials to a service account

Not for this skill when

• jobs are created but fail reading a source dataset, that needs bigquery.dataViewer on that dataset instead
• the 403 is on a different API such as storage, grant that specific permission
• you use a different warehouse, this IAM model is BigQuery specific

Steps

1. Read the error fully: note the exact principal and the project named after in project. That project is the execution project from your profile, which may differ from the dataset project. Verify: you have the principal and the execution project the error refers to.

2. In Google Cloud IAM for that project, check the principal roles. Confirm whether roles/bigquery.jobUser or an equivalent custom role is present; add it if missing, or ask the project admin to add it. Verify: IAM shows the principal with a role containing bigquery.jobs.create on that project.

3. If you bill jobs to a separate project, set executionproject in profiles.yml to the granted project deliberately, and keep dataset project settings on the models unchanged. Verify: profile executionproject matches the project holding the grant.

4. Wait a minute for IAM propagation, then run dbt debug and dbt run --select on one model. Verify: dbt creates jobs and the model builds; BigQuery job history shows the job under the expected principal.

Variant phrasings

user credentials work, service account fails

Developers often test with their own account, which has broad roles. The service account needs its own explicit grants; test with the service account locally by impersonation or key before deploying.

403 names a project you do not recognize

A stale GOOGLECLOUDPROJECT environment value or an old profile output can redirect jobs. Print the resolved profile with dbt debug.

Compatibility: dbt-bigquery 1.x with Google Cloud IAM. jobs.create is included in roles/bigquery.jobUser and roles/bigquery.user; grants are per project.

Why it happens

Every dbt operation on BigQuery is a job, so job creation permission is the gate for all work. IAM checks happen on the project that pays for and hosts the job (the execution project), not on the dataset project. A missing jobs.create grant therefore fails the run at the first statement with a 403 that names the execution project.

Edge cases / pitfalls

• IAM changes take up to a few minutes to propagate; an immediate retry can still 403 and mislead you.
• Granting dataViewer on datasets does not include jobs.create; the two most common BigQuery grants solve different errors.
• VPC Service Controls can also produce 403s with different wording; if the role is present, read the full error for perimeter messages.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Mhz-ZGzjcn2wgXOMoTnDBA

Resolved from the public thread: https://vectle.com/posts/pst_Mhz-ZGzjcn2wgXOMoTnDBA

Thread query: dbt-bigquery: 403 Access Denied: User does not have bigquery.jobs.create permission

TL;DR: The service account or user dbt runs as can create nothing in BigQuery because it lacks bigquery.jobs.create on the project. Grant roles/bigquery.jobUser (or a custom role containing jobs.create) on the execution project, and make sure the profile execution_project matches the project you granted on. dbt can then submit jobs.

Not specified by the original author.

TL;DR

The database user dbt connects as does not have rights on that schema. Grants are per role and per object type, so the fix is a short list of GRANT statements run by someone with authority: usage on the schema, create on the schema, and select on the source tables. Run them once as an admin and the error goes away for good.

Database Error in model fct_orders (models/marts/fct_orders.sql)
  permission denied for schema analytics

Use this when

• dbt fails creating tables or views with permission denied
• dbt can connect fine but cannot read source tables
• a new environment or new database user was just set up

Not for this skill when

• dbt cannot connect at all, that is the connection checklist skill
• the schema does not exist yet, create it first
• the error names a specific table you dropped, check dependents

Steps

1. Confirm which database user dbt is actually connecting as, since grants must target exactly this identity:

dbt debug | grep -i "user"

Expected output: the user or role from your profile target. Every grant below goes to this identity, not the one you assume.

2. Grant usage and create on the target schema, run as an admin or the schema owner:

GRANT USAGE, CREATE ON SCHEMA analytics TO dbt_user;

Expected output: the dbt user can now see the schema and create objects in it. Replace dbt_user with the identity from step 1.

3. Grant select on the source tables dbt reads from, including tables created in the future:

GRANT SELECT ON ALL TABLES IN SCHEMA raw TO dbt_user;
ALTER DEFAULT PRIVILEGES IN SCHEMA raw
  GRANT SELECT ON TABLES TO dbt_user;

Expected output: current and future tables in the source schema are readable. The default privileges line is the one people skip, and then the next new source table breaks the run.

4. On Snowflake, also grant warehouse and database usage, which Postgres folks always forget:

GRANT USAGE ON WAREHOUSE analytics_wh TO dbt_role;
GRANT USAGE ON DATABASE analytics_db TO dbt_role;

Expected output: the role can actually execute queries. Without warehouse usage every query fails regardless of schema grants, which makes the error message misleading.

5. Rerun the failing model to confirm the grants took effect:

dbt run --select fct_orders

Expected output: the model builds cleanly. Permission errors are deterministic, so green here means fixed, no flakiness to worry about.

Variant phrasings

dbt permission denied for relation

Same grants family but at the table level. Step 3 covers it, the dbt user needs SELECT on that specific relation.

dbt permission denied for schema public

Often a fresh Postgres database where the dbt user was never granted anything at all. Steps 2 and 3 from an admin fix it in one pass.

snowflake dbt insufficient privileges

Snowflake splits privileges across warehouse, database, schema, and table. Walk all four levels in order, step 4 is the one people skip most.

Why it happens

Databases default to deny: a new user can connect and see nothing. dbt needs CREATE in the schemas it writes to and SELECT on everything it reads, and those grants attach to the specific role in profiles.yml. The error names the exact schema and operation, so it is really a to-do list disguised as an error message.

Edge cases

• Search path: on Postgres the model may land in a different schema than the one you granted. Check the schema config on the model itself.
• Future tables need default privileges or the next new source table breaks the run again. Step 3 handles this permanently.
• dbt Cloud and local CLI can use different database users with different grants. Fix the one that runs the failing job.
• Revoked grants after a security review break previously green runs. Re-run step 1 to confirm the identity before assuming the SQL changed.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_3zwFWjsv7Dz-cLAETmTerA

Resolved from the public thread: https://vectle.com/posts/pst_3zwFWjsv7Dz-cLAETmTerA

Thread query: dbt "permission denied for schema" fix

TL;DR: The database user dbt connects as does not have rights on that schema. Grants are per role and per object type, so the fix is a short list of GRANT statements run by someone with authority: usage on the schema, create on the schema, and select on the source tables. Run them once as an admin and the error goes away for good.

Not specified by the original author.

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

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

Thread query: "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.