BigQuery IAM roles: which one to grant, and how to share a dataset
BigQuery separates two permissions people expect to come together: reading data and running queries. This guide lists the predefined roles from Google's reference, says which pair each kind of user needs, shows how to share a dataset in the console and with a GRANT statement, and how to see who already has access with INFORMATION_SCHEMA.
In BigQuery, reading data and running queries are separate permissions. A colleague with access to a dataset still cannot query it until they can also run jobs in some project. So the usual grant is a pair:
- BigQuery Data Viewer on the dataset, to read its tables;
- BigQuery Job User on a project, to run the query and be billed for it.
Most “Access Denied” messages come from having one of the two without the other.
| Role | Granted on | Lets them |
|---|---|---|
Data Viewer roles/bigquery.dataViewer |
dataset or table | read and export data, see metadata |
Data Editor roles/bigquery.dataEditor |
dataset | Data Viewer, plus create, update and delete tables and views, and change their data |
Data Owner roles/bigquery.dataOwner |
dataset | everything on the dataset and its contents, including sharing it |
Metadata Viewer roles/bigquery.metadataViewer |
dataset | see tables, schemas and access controls, not the data |
Job User roles/bigquery.jobUser |
project only | run jobs, including queries |
User roles/bigquery.user |
project or dataset | on a project: run jobs and create datasets; on a dataset: read metadata and list tables |
Read Session User roles/bigquery.readSessionUser |
project only | read through the Storage Read API, used by fast connectors |
Admin roles/bigquery.admin |
project | manage everything, including other users’ jobs |
The descriptions are summarised from Google’s BigQuery IAM roles reference, read on 16 October 2026.
Note: Rewritten in October 2026 against Google’s current documentation. The access listing and the GRANT statement below were run, or validated by a dry run, in BigQuery on 16 October 2026.
Which roles to give whom
| Person | Grant |
|---|---|
| An analyst who queries one dataset | Data Viewer on the dataset, Job User on the project that pays |
| An analyst who also builds tables in a work dataset | the above, plus Data Editor on the work dataset |
| A dashboard or BI tool’s service account | Data Viewer on the reporting dataset, Job User on its project; Read Session User if the tool reads through the Storage API |
| A pipeline that loads data | Data Editor on the target dataset, Job User on the project |
| Someone who needs to see what exists, not the data | Metadata Viewer |
| A person who manages access to a dataset | Data Owner on that dataset |
Grant at the narrowest level that works. A role on a project applies to every dataset in it; a role on a dataset applies to that dataset only. Google’s reference says Admin can be granted below project level but does not recommend it.
Job User decides who pays. The project where someone has Job User is the project their queries are billed to. Give it on the project that should carry the cost, not necessarily the one that holds the data.
Share a dataset
In the console
From Google’s dataset access page:
- In BigQuery Explorer, select the dataset.
- Click Sharing, then Permissions.
- Click Add principal, enter the person’s email or a group.
- Choose the role, for example BigQuery Data Viewer, and click Save.
Then make sure they can run queries: Job User on a project, granted in IAM & Admin.
With SQL
GRANT `roles/bigquery.dataViewer`
ON SCHEMA `myproject.mydataset`
TO "user:analyst@example.com";This statement was validated by a dry run, which checks it without granting anything. REVOKE takes the same form. A group, "group:analysts@example.com", is easier to maintain than a list of people.
Google notes one limit: you cannot grant access while creating a dataset in the console or bq; create it first, then share it.
OWOX Data Marts
See your first report built in real time. 15 minutes.
- Connect your data warehouse
- Pick your metrics
- Get a live Google Sheets report
In the time it takes to write a ticket. Then imagine never writing that ticket again.
Book a DemoWe'll use your actual use case
See who has access
SELECT privilege_type, grantee
FROM `myproject.region-us.INFORMATION_SCHEMA.OBJECT_PRIVILEGES`
WHERE object_name = 'searchconsole';On a Search Console export dataset in our project this returned five rows (emails shortened):
| privilege_type | grantee |
|---|---|
| roles/bigquery.dataEditor | projectEditor:… |
| roles/bigquery.dataEditor | user:…@owox.com |
| roles/bigquery.dataOwner | projectOwner:… |
| roles/bigquery.dataOwner | serviceAccount:search-console-data-export@system.gserviceaccount.com |
| roles/bigquery.dataViewer | projectViewer:… |
Two things it shows. Project roles reach the dataset by default: project owners, editors and viewers get Data Owner, Data Editor and Data Viewer on it. And a service account set up for one integration can hold more than it was given at setup: here the Search Console export account holds Data Owner on its dataset. Audit the list from time to time, not only at setup.
The errors and what they mean
- “Access Denied: Project …: User does not have bigquery.jobs.create permission”: no Job User on the project you are running the query in. Grant it, or choose a project where they have it.
- “Access Denied: Table …: User does not have permission to query table”: no read role on that dataset or table.
- A dashboard stops working when someone leaves: it was running with that person’s credentials. Run shared reports under a service account.
Who ran what, and what it cost, is in the BigQuery job history. Restoring something a wrong grant let someone delete is in restoring deleted tables.
Access to tables, and access to definitions
Access to tables, and access to definitions
IAM decides who can read a table. It does not decide which table a report should read, or what its columns mean, and that is where most wrong numbers come from: a colleague with Data Viewer on the raw dataset builds their own revenue query.
A common setup gives analysts Data Editor on a modelling dataset and gives everyone else access only to the prepared results. In OWOX Data Marts those results are Data Marts: each one a query with an owner and a description per column, delivered to the sheets and people use, so business users do not need BigQuery roles at all. OWOX Data Marts runs the SQL as written, in your own BigQuery project, under the storage credentials you give it, and does not transform the data.
Turn your data into decisions.
Governed data marts give you the clean foundation ML needs to actually work.
- No AI hallucinations
- Analyst-governed definitions
- Every number traces to SQL
Frequently Asked Questions
What are the best practices for BigQuery IAM roles?
Grant at the narrowest level that works: read roles on datasets, Job User on the project that should pay. Use groups rather than individual emails, run shared dashboards under a service account, and review who has access with INFORMATION_SCHEMA.OBJECT_PRIVILEGES from time to time.
How do I share a BigQuery dataset with another user?
In BigQuery Explorer, select the dataset, click Sharing, then Permissions, then Add principal, enter the email and choose a role such as BigQuery Data Viewer. Or run GRANT `roles/bigquery.dataViewer` ON SCHEMA `project.dataset` TO "user:name@example.com". They also need Job User on a project to run queries.
Why can a user see a BigQuery dataset but not query it?
Reading data and running queries are separate permissions. Data Viewer on the dataset lets them read it; Job User (or BigQuery User) on a project lets them run the query. Without the second, the query fails with a bigquery.jobs.create permission error.
At which levels can BigQuery roles be granted?
On the organization, folder, project, dataset, and for read roles on a table or view. A role on a project applies to every dataset in it. Job User and Read Session User can only be granted on projects and above.
What is the difference between BigQuery Data Viewer, Data Editor and Data Owner?
Data Viewer reads and exports data. Data Editor also creates, changes and deletes tables and views and their data. Data Owner can do everything on the dataset, including managing who has access to it.
What does BigQuery Job User allow?
Running jobs, including queries, loads and exports, in a project, and the jobs are billed to that project. It gives no access to data by itself; pair it with a read role on the datasets the person needs.
