Skip to main content
In Firebolt, system-defined roles are automatically created for each organization and account. These roles provide predefined privileges and serve specific purposes. System-defined roles cannot be dropped, and you can grant any of them additional privileges. Their built-in privileges cannot be revoked, with one exception: public, covered under public privileges.

​
Organization system roles

Organization-level roles, logins, and service accounts are not supported in Firebolt OSS.
The organization_admin role cannot be granted using SQL. It can only be granted using the Firebolt Workspace user interface (UI). To manage resources at the organization level, you must assign the organization_admin role to your login using the UI.

​
Account system roles

By default, every newly created user is granted the public role. You can also revoke this role from a user.

​
Default privileges for system roles

System roles come with predefined default privileges that are automatically applied when objects are created. These default privileges are built into the system and cannot be revoked, with one exception: public, from which an account_admin can revoke a system-defined privilege.

​
account_admin privileges

The account_admin role has comprehensive default privileges across the entire account:
  • Account-level: Full administrative access including user and role management
  • Database-level: CREATE, MODIFY, USAGE, and DROP on all databases
  • Schema-level: Default privileges include CREATE, MODIFY, USAGE, and DROP on all schemas
  • Table-level: Default privileges include SELECT, INSERT, UPDATE, DELETE, TRUNCATE, and DROP on all tables
  • Engine-level: Full engine management and monitoring capabilities
  • Location-level: Full location management and configuration capabilities
  • User-level: Full user management and administration capabilities
  • Role-level: Full role management and administration capabilities

​
system_admin privileges

The system_admin role has operational privileges for database and engine management:
  • Database-level: CREATE, MODIFY, USAGE, and DROP on all databases
  • Schema-level: Default privileges include CREATE, MODIFY, USAGE, and DROP on all schemas
  • Table-level: Default privileges include SELECT, INSERT, UPDATE, DELETE, TRUNCATE, and DROP on all tables
  • Engine-level: Engine management and monitoring capabilities
  • Limitation: Cannot manage users, roles, or account-level settings

​
public privileges

The public role lets a user reach objects, not use them. It is navigational only:
  • Database-level: USAGE on all databases
  • Schema-level: USAGE on each database’s public schema, granted when the database is created
  • Table-level: No default table privileges. SELECT, INSERT, UPDATE, DELETE, and TRUNCATE must all be granted explicitly.
  • Object creation: None. Creating a table, view, index, or external table in a public schema requires an explicit CREATE grant.
  • Location-level: None. Reading through a location requires an explicit USAGE grant on that location, or USAGE ANY LOCATION.
A user holding only public can connect, reach a database and its public schema, and read a privilege-filtered catalog. Everything else requires a grant.
Firebolt narrowed this role, and applies the narrower set only when it creates something new: the account-level privileges above are written when an account is created, and the public-schema USAGE when a database is created. Firebolt never rewrites the privileges of an account or a database that already exists.So an account created before the change keeps a public that also holds USAGE ANY LOCATION, and a database created before it keeps a public that also holds CREATE on its public schema. An account_admin narrows them by hand — and only an account_admin can: every GRANT and REVOKE naming the public role requires that role, so owning a database is not enough to narrow the public privileges on its own public schema, even though the database owner owns that schema. Location usage is one statement for the account:
Object creation is one statement per database, naming that database’s public schema:
Both are reversible: GRANT the same privilege back if you overshoot. Query information_schema.object_privileges to see which of them a given database still holds.Object creation also has an account-wide form, in the other direction. ALTER DEFAULT PRIVILEGES sets what a role receives on schemas created afterwards, so one statement restores CREATE for public going forward:
ALTER DEFAULT PRIVILEGES REVOKE CREATE ON SCHEMAS FROM public takes it back, and this reaches new schemas only — a database that already exists still needs its own GRANT CREATE ON SCHEMA my_database.public TO public.Note that it restores more than the privilege it replaces. A default privilege applies to every schema created afterwards, so it covers schemas made with CREATE SCHEMA as well as the public schema of each new database; the built-in grant it stands in for only ever covered the latter. If you want the narrower thing, grant CREATE per database on that database’s public schema instead.

​
Important notes about system role privileges

  • Immutable privileges: Default privileges for account_admin and system_admin are hardcoded and cannot be modified using ALTER DEFAULT PRIVILEGES or REVOKE commands
  • Automatic application: These default privileges apply immediately when objects are created, without requiring explicit grants
  • Additional privileges: You can grant additional privileges to any system role
  • The public exception: public is the one system role whose built-in privileges an account_admin can revoke, and grant back
  • Write time only: The sets above are written when an account or a database is created. Firebolt does not retroactively change the privileges of an account or a database that already exists.
To view the current default privileges for system roles, query the object_default_privileges information schema view: