Skip to main content
The GRANT controls each for interacting with specific , , , or . For privileges required by specific statements, see the documentation for the respective . You can use GRANT to directly grant privileges to a role or user, or you can grant membership to an existing role, which grants that role’s privileges to the grantee. Users granted a privilege with WITH GRANT OPTION can in turn grant that privilege to others. The owner of an object implicitly has the GRANT OPTION for all privileges, and the GRANT OPTION is inherited through role memberships. For new databases, users with the following roles are automatically granted the :
  • Every user who is part of (including ).
  • Every user who is part of for the new database.
The GRANT statement performs a schema change. For more information about how online schema changes work in CockroachDB, see .

Syntax

grant syntax diagram

Parameters

ParameterDescription
ALL ALL PRIVILEGESGrant all privileges.
privilege\_listA comma-separated list of privileges to grant. For guidelines, see .
grant\_targetsA comma-separated list of database, table, sequence, or function names. The list should be preceded by the object type (e.g., DATABASE mydatabase). If the object type is not specified, all names are interpreted as table or sequence names.
target\_typesA comma-separated list of .
ALL SEQUENCES IN SCHEMAGrant privileges on all sequences in a schema or list of schemas.
ALL TABLES IN SCHEMAGrant privileges on all tables and sequences in a schema or list of schemas.
ALL FUNCTIONS IN SCHEMAGrant privileges on all in a schema or list of schemas.
schema\_name\_listA comma-separated list of .
role\_spec\_listA comma-separated list of .
WITH ADMIN OPTIONDesignate the user as a role admin. Role admins can grant or membership for the specified role.
WITH GRANT OPTIONAllow the user to grant the specified privilege to others.

Supported privileges

Roles and users can be granted the following privileges:
PrivilegeLevelsDescription
ALLSystem, Database, Schema, Table, Sequence, TypeFor the object to which ALL is applied, grants all privileges at the system, database, schema, table, sequence, or type level.
BACKUPSystem, Database, TableGrants the ability to create at the system, database, or table level.
BYPASSRLSTableGrants the ability to bypass policies on a table. This privilege controls the access from an RLS perspective only; the user also needs sufficient privileges to read or write to the table.
CANCELQUERYSystemGrants the ability to cancel queries.
CHANGEFEEDTableGrants the ability to create on a table.
CONNECTDatabaseGrants the ability to view a database’s metadata, which consists of objects in a database’s information\_schema and pg\_catalog system catalogs. This allows the role to view the database’s table, schemas, user-defined types, and list the database when running SHOW DATABASES. The CONNECT privilege is also required to run backups of the database.
CONTROLJOBSystemGrants the ability to , , and jobs. Non-admin roles cannot control jobs created by admin roles.
CREATEDatabase, Schema, Table, SequenceGrants the ability to create objects at the database, schema, table, or sequence level. When applied at the database level, grants the ability to configure . In CockroachDB v23.2 and later, the sql.auth.public\_schema\_create\_privilege.enabled controls whether users receive CREATE privileges on the public schema or not. The setting applies at the time that the , which happens whenever . The setting is true by default, but can be set to false for increased compatibility with PostgreSQL version 15 as described in this commit.
CREATEDBSystemGrants the ability to or a database.
CREATELOGINSystemGrants the ability to manage authentication using the WITH PASSWORD, VALID UNTIL, and LOGIN/NOLOGIN role options.
CREATEROLESystemGrants the ability to , modify, or non-admin roles.
DELETETable, SequenceGrants the ability to delete objects at the table or sequence level.
DROPDatabase, Table, SequenceGrants the ability to drop objects at the database, table, or sequence level.
EXECUTEFunctionGrants the ability to execute .
EXTERNALCONNECTIONSystemGrants the ability to connect to external systems such as object stores, key management systems, Kafka feeds, or external file systems. Often used in conjunction with the BACKUP, RESTORE, and CHANGEFEED privilege.
EXTERNALIOIMPLICITACCESSSystemGrants the ability to interact with external resources that require implicit access.
INSERTTable, SequenceGrants the ability to insert objects at the table or sequence level.
INSPECTSystemGrants the ability to run the statement and view results with .
MODIFYCLUSTERSETTINGSystemGrants the ability to modify .
MODIFYSQLCLUSTERSETTINGSystemGrants the ability to modify SQL (cluster settings prefixed with sql.).
NOSQLLOGINSystemPrevents roles from connecting to the SQL interface of a cluster.
DeprecatedREPLICATIONSystemAs of v25.2 REPLICATION is deprecated. Instead, use the REPLICATIONSOURCE and REPLICATIONDEST privileges at the table level. Grants the ability to create a or stream.
REPAIRCLUSTER, REPAIRCLUSTERMETADATASystemGrants the ability to perform cluster debugging and repair operations, including: edit , edit , , update , and . See also: VIEWCLUSTERMETADATA.
REPLICATIONDESTTableGrants the ability to run logical data replication into an existing table on the destination cluster. For more details, refer to the tutorial.
REPLICATIONSOURCETableGrants the ability to run logical data replication from a table on the source cluster. For more details, refer to the tutorial.
RESTORESystem, DatabaseGrants the ability to restore at the system or database level. Refer to RESTORE for more details.
SELECTTable, SequenceGrants the ability to run at the table or sequence level.
TRIGGERTableGrants the ability to create on a table.
UPDATETable, SequenceGrants the ability to run at the table or sequence level.
USAGESchema, Sequence, TypeGrants the ability to use , , or .
VIEWACTIVITYSystemGrants the ability to view other user’s activity statistics of a cluster.
VIEWACTIVITYREDACTEDSystemGrants the ability to view other user’s activity statistics, but prevents the role from accessing the statement diagnostics bundle in the DB Console, and viewing some columns in introspection queries that contain data about the cluster.
VIEWCLUSTERMETADATASystemGrants the ability to view range information, data distribution, store information, and Raft information.
VIEWCLUSTERSETTINGSystemGrants the ability to view and their values.
VIEWDEBUGSystemGrants the ability to view the of the DB Console and work with the debugging and profiling endpoints.
VIEWJOBSystemGrants the ability to view on the cluster.
VIEWSYSTEMTABLESystemGrants read-only access (SELECT) on all tables in the system database, without granting the ability to modify the cluster. This privilege was introduced in v23.1.11.
ZONECONFIGDatabase, Table, SequenceGrants the ability to configure at the database, table, and sequence level.

Required privileges

  • To grant privileges, the user granting the privileges must also have the privilege being granted on the target database or tables. For example, a user granting the SELECT privilege on a table to another user must have the SELECT privileges on that table and WITH GRANT OPTION on SELECT.
  • To grant roles, the user granting role membership must be a role admin (i.e., members with the WITH ADMIN OPTION) or a member of the admin role. To grant membership to the admin role, the user must have WITH ADMIN OPTION on the admin role.

Details

Granting privileges

When a role or user is granted privileges for a table, the privileges are limited to the table. The user does not automatically get privileges to new or existing tables in the database. To grant privileges to a user on all new and/or existing tables in a database, see Grant privileges on all tables in a database. For privileges required by specific statements, see the documentation for the respective .

Granting roles

  • Users and roles can be members of roles.
  • The root user is automatically created as an admin role and assigned the ALL privilege for new databases.
  • All privileges of a role are inherited by all its members.
  • Membership loops are not allowed (direct: A is a member of B is a member of A or indirect: A is a member of B is a member of C... is a member of A ).
  • When you grant role membership (for example, GRANT {role} TO {user} ), CockroachDB waits for full-cluster visibility of the updated role metadata. The operation is not blocked by long-running transactions that may have accessed older metadata, and it does not create a .

Known limitations

User/role management operations (such as and ) are . As such, they inherit the . For example, schema changes wait for concurrent using the same resources as the schema changes to complete. In the case of being modified inside a transaction, most transactions need access to the set of role memberships. Using the default settings, role modifications require schema leases to expire, which can take up to 5 minutes. This means that elsewhere in the system can cause user/role management operations inside transactions to take several minutes to complete. This can have a cascading effect. When a user/role management operation inside a transaction takes a long time to complete, it can in turn block all user-initiated transactions being run by your application, since the user/role management operation in the transaction has to commit before any other transactions that access role memberships (i.e., most transactions) can make progress. If you want user/role management operations to finish more quickly, and do not care whether concurrent transactions will immediately see the side effects of those operations, set the allow_role_memberships_to_change_during_transaction to true. When this session variable is enabled, any user/role management operations issued in the current session will only need to wait for the completion of statements in other sessions where allow_role_memberships_to_change_during_transaction is not enabled. To accelerate user/role management operations across your entire application, you have the following options:
  1. Set the session variable in all sessions by .
  2. Apply the allow_role_memberships_to_change_during_transaction setting globally to an entire cluster using the statement:

Examples

Setup

To follow along, run to start a temporary, in-memory cluster with the sample dataset preloaded:

Grant privileges on databases

Grant privileges on specific tables in a database

Grant privileges on all tables in a database or schema

To grant all the privileges on existing tables to a user:
To ensure that anytime a new table is created, all the privileges on that table are granted to a user, use :
To check that this is working as expected, :
Then, check that the all privileges on the newly created table are granted to the user you specified using :

Grant system-level privileges on the entire cluster

live above the database level and apply to the entire cluster. root and users have system-level privileges by default, and are capable of granting it to other users and roles using the GRANT statement. For example, the following statement allows the user max (created in a previous example) to use the statement by assigning the MODIFYCLUSTERSETTING system privilege:

Make a table readable to every user in the system

Grant privileges on schemas

Grant privileges on user-defined types

To grant privileges on , use the following statements.

Grant the privilege to manage the replication zones for a database or table

The user max can then use the statement to add, modify, reset, or remove replication zones for the table rides.

Grant role membership

Grant the admin option

Grant privileges with the option to grant to others

See also