Skippr Docs

Appearance

How to Grant BigQuery Dataset Permissions ​

August 2026

BigQuery dataset permissions are correct when the service account can create datasets if needed, create or update tables, and run the jobs required to load data in the target project.

Short Answer ​

To grant BigQuery dataset permissions, start with the service account that will actually run the workload and give it the permissions BigQuery needs to create datasets, create tables, update table data, and run jobs. The docs call out the underlying permissions directly: bigquery.datasets.create, bigquery.tables.create, bigquery.tables.updateData, and bigquery.jobs.create, which are covered by the common BigQuery Data Editor and BigQuery Job User roles.

The authentication path is equally important. BigQuery access in Skippr uses a GCP service account JSON key file through GOOGLE_APPLICATION_CREDENTIALS, so the first practical setup is one service account, one downloaded JSON key, one target project, one dataset such as raw_data, and one location such as US. If the same identity can create or reach the dataset and run a load job, the permission story is basically in place.

Why Teams Struggle with This ​

BigQuery permission issues usually come from granting roles to the wrong identity or only partially covering the workload. A green-looking GCP setup can still fail the first write because the service account can authenticate but not create jobs or datasets.

  • The roles have to be granted to the exact service account referenced by GOOGLE_APPLICATION_CREDENTIALS, not to a different human user or a similarly named service account.
  • Dataset creation and job execution are separate capabilities. A service account can sometimes read metadata and still fail when it tries to create the dataset or launch the load.
  • If the target project is not the one you think it is, a correct dataset name still results in Access Denied or Not found style failures.
  • A dataset location mismatch is not the same as a permission issue, but teams often confuse the two when they are debugging the first BigQuery run.

How Skippr Handles It ​

Skippr keeps the BigQuery destination compact enough that permission debugging stays practical. The runtime contract is just project, dataset, and optional location, with Google authentication coming from the standard service-account key path.

That means the first destination review can stay focused on the real boundary: which project should receive the data, which dataset should hold bronze tables, and whether the chosen service account can create datasets, create tables, update data, and submit jobs there.

  • Uses GOOGLE_APPLICATION_CREDENTIALS for the service account key path.
  • Requires only project, dataset, and optional location in the BigQuery warehouse config.
  • Can create downstream silver and gold datasets when the service account has the documented dataset-creation permission.
  • Maps cleanly to the documented Access Denied: Dataset and Not found: Dataset troubleshooting paths.

What the First Useful Version Looks Like ​

The first useful version is one GCP project, one service account, one dataset name, and one successful write path into raw tables. That proves both authentication and authorization without mixing in every downstream concern at the same time.

After that, keep the model simple: reuse the same service account for the destination workload, keep the dataset names explicit in config, and widen permissions only when there is a real reason. BigQuery access is easiest to maintain when the workload identity and the target project stay stable.