Access control
Access is per catalog. Admins create roles, grant each role read or
write on catalogs, and add members to roles.
Settings → Roles.
| Grant | The member can |
|---|---|
read | Query the catalog. Any write to it is refused |
write | Query it, and run INSERT, UPDATE, DELETE, CREATE, DROP and ALTER against it, if the catalog itself is writable |
| none | The catalog doesn't exist for them: it is hidden from the Tables page, autocomplete and the AI tools, and queries naming it fail |
Defaults
- Until your company creates its first role, every member has
writeon every catalog. Creating a role is what switches access control on. - Admins always have
writeon every catalog. - A member in several roles gets the stronger grant for each catalog, so adding a role never takes access away.
Everything follows the same grants
The grants apply wherever a query comes from: Studio, the API and drivers (JDBC, SQLAlchemy, .NET), AI assistants over MCP, and scheduled jobs, which run with their owner's access. Pipeline branch runs are limited to the catalogs the person starting them can see, and write only to dev catalogs.
Read-only catalogs
Independently of roles, a PostgreSQL, MySQL or BigQuery catalog can be marked read-only when it is registered. Nobody can write through it, admins included. Use this for sources you only ever read from, and give the source credentials read-only permissions in the source system as well.