Data & Analytics
dbt v2 BigQuery location lookup can widen IAM requirements
Investigate a dbt v2 BigQuery 403 caused by project-level SCHEMATA access when the runner is scoped to one dataset.
November 5, 2026
A dbt runner has rights on its target BigQuery dataset and succeeds on dbt Core v1. The same model fails on public dbt v2 with a 403 against INFORMATION_SCHEMA.SCHEMATA. The issue author traced the difference to dataset-location lookup: v1 reads one dataset's metadata, while v2 queries a project-scoped metadata view. Google's SCHEMATA documentation says that view requires bigquery.datasets.get at project level.
Confirm which lookup failed
Preserve the full 403, dbt version, impersonated service account, target dataset, and the SQL or API call visible in logs. Verify that the runner can read target-dataset metadata and execute its normal jobs. The reproduction uses table-level grants to reach the location lookup, but the underlying failure is the metadata scope. Avoid confusing a grant application problem with the earlier location query.
Protect least privilege during migration
Compare the actual permissions required by v1 and v2 in a disposable project. Do not grant project-wide metadata access just to clear a migration gate without a security review; it may reveal dataset inventory beyond the intended scope. Keep the production runner on the known-good version while testing a supported fix or a narrowly approved access design. The reporter tested a patched prototype, but that is not evidence that the public v2 binary has the fix.
Set the acceptance test
Use a service account with dataset-level access only and a model that triggers the location lookup. Assert that the model builds, the intended table grant is applied, and the service account still lacks unrelated project metadata access. Repeat on the exact release candidate. Give the platform team a permission diff, not a request to “make dbt admin.”
Adovo’s view
An upgrade should not quietly redraw a security boundary. If a tool needs a broader view of the warehouse, make that dependency explicit and justify it. The right outcome is a working build with an access scope the data owner can defend.