Stay organized with collections
Save and categorize content based on your preferences.
This page describes the privileges that you can grant to a database role for
fine-grained access control. This information applies to both GoogleSQL-dialect databases and PostgreSQL-dialect databases.
The following sections provide details about each privilege.
SELECT
Allows the role to read or query from a table, view, change stream, sequence, or
model.
If a column list is specified for a table, the privilege is valid on only
those columns. If no column list is specified, then the privilege is valid
on all columns in the table, including columns added afterward. A column
list isn't allowed for a view.
Spanner supports both invoker's rights views and definer's
rights views. For more information, see Views overview.
If you create a view with invoker's rights, to query the view, the database
role or user needs the SELECT privilege on the view, and also the SELECT
privilege on the underlying objects referenced in the view. For example,
suppose the view SingerNames is created on the Singers table.
Suppose that the database role myRole performs the query SELECT * FROM
SingerNames. The role must have SELECT privilege on the view and must
have SELECT privilege on the three referenced columns or on the entire
Singers table.
If you create a view with definer's rights, to query the view, the database
role or user only needs the SELECT privilege on the view. For example,
suppose the view AlbumsBudget is created on the Albums table.
Suppose that the database role Analyst performs the query SELECT * FROM
AlbumsBudget. The role only needs SELECT privilege on the view. It
doesn't need the SELECT privilege on the three referenced columns or on
the Albums table.
After granting SELECT on a subset of columns for a table, the FGAC user
can no longer use SELECT * on that table. Queries on that table must name
all columns to be included.
SELECT granted on a generated column doesn't grant SELECT on the
underlying base columns.
For interleaved tables, SELECT granted on the parent table doesn't
propagate to the child table.
When you grant SELECT on a change stream, you must also grant EXECUTE on
the table-valued function for the change stream. For more information, see
EXECUTE.
When SELECT is used with an aggregate function on specific columns, for
example SUM(col_a), the role must have the SELECT privilege on those
columns. If the aggregate function doesn't specify any columns, for example
COUNT(*), the role must have the SELECT privilege on at least one column
in the table.
When you use SELECT with a sequence, you can only view sequences that you
have privileges to view.
Allows the role to insert rows into the specified tables. If a column list is
specified, the permission is valid on only those
columns. If no column list is specified, then the privilege is valid on all
columns in the table.
If column names are specified, any column not included gets its default
value upon insert.
Allows the role to update rows in the specified tables. Updates can be
restricted to a subset of table columns. When you use this with sequences, it
allows the role to call the get-next-sequence-value function on the sequence.
In addition to the UPDATE privilege, the role needs the SELECT privilege on
all queried columns. Queried columns include columns in the WHERE clause.
Allows the role to delete rows from the specified tables.
DELETE can't be granted at the column level.
The role also needs SELECT on any columns that might be
included in the query's WHERE clauses.
For interleaved tables in GoogleSQL-dialect databases, the
DELETE privilege is required only on the parent table. If a child table
specifies ON DELETE CASCADE, rows from the child table are deleted even without
the DELETE privilege on the child table.
When you grant SELECT on a change stream, you must also grant EXECUTE on the
read function for the change stream. For more information, see
Change stream read functions and query syntax.
When you grant USAGE to a named schema, it provides privileges to access
objects contained in the named schema. The USAGE privilege is granted, by
default, to the default schema.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-28 UTC."],[],[],null,["# Fine-grained access control privileges\n\nThis page describes the privileges that you can grant to a database role for\nfine-grained access control. This information applies to both GoogleSQL-dialect databases and PostgreSQL-dialect databases.\n\nTo learn about database roles and fine-grained access control, see\n[Fine-grained access control overview](/spanner/docs/fgac-about).\n\nThe following table shows the fine-grained access control privileges and the database objects\nthat they can be granted on.\n\nThe following sections provide details about each privilege.\n\n`SELECT`\n--------\n\nAllows the role to read or query from a table, view, change stream, sequence, or\nmodel.\n\n- If a column list is specified for a table, the privilege is valid on only\n those columns. If no column list is specified, then the privilege is valid\n on all columns in the table, including columns added afterward. A column\n list isn't allowed for a view.\n\n- Spanner supports both invoker's rights views and definer's\n rights views. For more information, see [Views overview](/spanner/docs/views).\n\n If you create a view with invoker's rights, to query the view, the database\n role or user needs the `SELECT` privilege on the view, and also the `SELECT`\n privilege on the underlying objects referenced in the view. For example,\n suppose the view `SingerNames` is created on the `Singers` table. \n\n CREATE VIEW SingerNames SQL SECURITY INVOKER AS\n SELECT Singers.SingerId, Singers.FirstName, Singers.LastName FROM Singers;\n\n Suppose that the database role `myRole` performs the query `SELECT * FROM\n SingerNames`. The role must have `SELECT` privilege on the view and must\n have `SELECT` privilege on the three referenced columns or on the entire\n `Singers` table.\n\n If you create a view with definer's rights, to query the view, the database\n role or user only needs the `SELECT` privilege on the view. For example,\n suppose the view `AlbumsBudget` is created on the `Albums` table. \n\n CREATE VIEW AlbumsBudget SQL SECURITY DEFINER AS\n SELECT Albums.Id, Albums.AlbumTitle, MarketingBudget FROM Albums;\n\n Suppose that the database role `Analyst` performs the query `SELECT * FROM\n AlbumsBudget`. The role only needs `SELECT` privilege on the view. It\n doesn't need the `SELECT` privilege on the three referenced columns or on\n the `Albums` table.\n- After granting `SELECT` on a subset of columns for a table, the FGAC user\n can no longer use `SELECT *` on that table. Queries on that table must name\n all columns to be included.\n\n- `SELECT` granted on a generated column doesn't grant `SELECT` on the\n underlying base columns.\n\n- For interleaved tables, `SELECT` granted on the parent table doesn't\n propagate to the child table.\n\n- When you grant `SELECT` on a change stream, you must also grant `EXECUTE` on\n the table-valued function for the change stream. For more information, see\n [EXECUTE](#execute-privilege).\n\n- When `SELECT` is used with an aggregate function on specific columns, for\n example `SUM(col_a)`, the role must have the `SELECT` privilege on those\n columns. If the aggregate function doesn't specify any columns, for example\n `COUNT(*)`, the role must have the `SELECT` privilege on at least one column\n in the table.\n\n- When you use `SELECT` with a sequence, you can only view sequences that you\n have privileges to view.\n\n#### Examples for using `GRANT SELECT`\n\n### GoogleSQL\n\n```googlesql\nGRANT SELECT ON TABLE employees TO ROLE hr_director;\n\nGRANT SELECT ON TABLE customers, orders, items TO ROLE account_mgr;\n\nGRANT SELECT(name, level, cost_center, location, manager) ON TABLE employees TO ROLE hr_manager;\n\nGRANT SELECT(name, address, phone) ON TABLE employees, contractors TO ROLE hr_rep;\n\nGRANT SELECT ON VIEW orders_view TO ROLE hr_manager;\n\nGRANT SELECT ON CHANGE STREAM ordersChangeStream TO ROLE hr_analyst;\n\nGRANT SELECT ON SEQUENCE sequence_name TO ROLE role_name;\n```\n\n### PostgreSQL\n\n```postgresql\nGRANT SELECT ON TABLE employees TO hr_director;\n\nGRANT SELECT ON TABLE customers, orders, items TO account_mgr;\n\nGRANT SELECT(name, level, cost_center, location, manager) ON TABLE employees TO hr_manager;\n\nGRANT SELECT(name, address, phone) ON TABLE employees, contractors TO hr_rep;\n\nGRANT SELECT ON TABLE orders_view TO hr_manager; // orders_view is an invoker rights view\n\nGRANT SELECT ON CHANGE STREAM orders_change_stream TO hr_analyst;\n\nGRANT SELECT ON SEQUENCE sequence_name TO hr_package;\n```\n\n`INSERT`\n--------\n\nAllows the role to insert rows into the specified tables. If a column list is\nspecified, the permission is valid on only those\ncolumns. If no column list is specified, then the privilege is valid on all\ncolumns in the table.\n\n- If column names are specified, any column not included gets its default\n value upon insert.\n\n- `INSERT` can't be granted on generated columns.\n\n#### Examples for using `GRANT INSERT`\n\n### GoogleSQL\n\n```googlesql\nGRANT INSERT ON TABLE employees, contractors TO ROLE hr_manager;\n\nGRANT INSERT(name, address, phone) ON TABLE employees TO ROLE hr_rep;\n```\n\n### PostgreSQL\n\n```postgresql\nGRANT INSERT ON TABLE employees, contractors TO hr_manager;\n\nGRANT INSERT(name, address, phone) ON TABLE employees TO hr_rep;\n```\n\n`UPDATE`\n--------\n\nAllows the role to update rows in the specified tables. Updates can be\nrestricted to a subset of table columns. When you use this with sequences, it\nallows the role to call the `get-next-sequence-value` function on the sequence.\n\nIn addition to the `UPDATE` privilege, the role needs the `SELECT` privilege on\nall queried columns. Queried columns include columns in the `WHERE` clause.\n\n`UPDATE` can't be granted on generated columns.\n\n#### Examples for using `GRANT UPDATE`\n\n### GoogleSQL\n\n```googlesql\nGRANT UPDATE ON TABLE employees, contractors TO ROLE hr_manager;\n\nGRANT UPDATE(name, address, phone) ON TABLE employees TO ROLE hr_rep;\n```\n\n### PostgreSQL\n\n```postgresql\nGRANT UPDATE ON TABLE employees, contractors TO hr_manager;\n\nGRANT UPDATE(name, address, phone) ON TABLE employees TO hr_rep;\n```\n\n`DELETE`\n--------\n\nAllows the role to delete rows from the specified tables.\n\n- `DELETE` can't be granted at the column level.\n\n- The role also needs `SELECT` on any columns that might be\n included in the query's `WHERE` clauses.\n\n- For interleaved tables in GoogleSQL-dialect databases, the\n `DELETE` privilege is required only on the parent table. If a child table\n specifies `ON DELETE CASCADE`, rows from the child table are deleted even without\n the `DELETE` privilege on the child table.\n\n#### Example for using `GRANT DELETE`\n\n### GoogleSQL\n\n```googlesql\nGRANT DELETE ON TABLE employees, contractors TO ROLE hr_admin;\n```\n\n### PostgreSQL\n\n```postgresql\nGRANT DELETE ON TABLE employees, contractors TO hr_admin;\n```\n\n`EXECUTE`\n---------\n\nWhen you grant `SELECT` on a change stream, you must also grant `EXECUTE` on the\nread function for the change stream. For more information, see\n[Change stream read functions and query syntax](/spanner/docs/change-streams/details#change_stream_query_syntax).\n\nWhen you use this with models, it allows the role to use the model in\n[machine learning functions](/spanner/docs/reference/standard-sql/ml-functions).\n\n#### Example for using `GRANT EXECUTE`\n\nThe following example shows how to grant `EXECUTE` on the read function for the\nchange stream named `my_change_stream`. \n\n### GoogleSQL\n\n```googlesql\nGRANT EXECUTE ON TABLE FUNCTION READ_my_change_stream TO ROLE hr_analyst;\n```\n\n### PostgreSQL\n\n```postgresql\nGRANT EXECUTE ON FUNCTION spanner.read_json_my_change_stream TO hr_analyst;\n```\n\nUSAGE\n-----\n\nWhen you grant `USAGE` to a named schema, it provides privileges to access\nobjects contained in the named schema. The `USAGE` privilege is granted, by\ndefault, to the default schema.\n\nWhat's next\n-----------\n\n- [Configure fine-grained access control](/spanner/docs/configure-fgac)\n- [Fine-grained access control overview](/spanner/docs/fgac-about)\n- [GRANT and REVOKE statements](/spanner/docs/reference/standard-sql/data-definition-language#grant_and_revoke_statements) (GoogleSQL-dialect databases)\n- [GRANT and REVOKE statements](/spanner/docs/reference/postgresql/data-definition-language#grant_and_revoke_statements) (PostgreSQL-dialect databases)"]]