connect_catalog(endpoint) itself. This page covers what it takes to reach
a brand new deployment for the first time.
Initial access
A newly deployed catalog has no databases and no grants: nobody yet holdsCREATE_DATABASE or any other system-level privilege, so there is nothing
for an ordinary principal to do with a catalog connection. Database
administration starts from a superuser.
Superuser
A superuser is an identity your deployment operator configures outside the normal grant system, not a role anyone can be granted. It bypasses privilege checks entirely, on every object, rather than holding specific privileges — the same wayOWNERSHIP on an object grants full authority
over that one object, a superuser has it over the whole deployment.
This is what makes a brand new deployment usable. Creating a database or
namespace can fall back to a system or parent-namespace privilege when the
object has no owner yet — see
Creating an object you don’t own yet —
but a system-level privilege itself has no such fallback, so a superuser
signs in first and grants CREATE_DATABASE, OPERATE, or other system
privileges to real principals and roles. Day-to-day administration then
runs through those grants, the same as any other object; reach for the
superuser identity to recover access or bootstrap a new deployment, not as
a standing way to work.
Privileges
The catalog connection itself is gated by privileges on thesystem
object: CREATE_DATABASE to create one, OPERATE to manage jobs, caches,
server configuration and role membership, and USAGE to list jobs and look
up other identities. See Privileges for the full
table and how a grant is addressed, and
Principals for who a grant can name.
What to read next
Catalog Hierarchy
How the catalog relates to databases, namespaces and tables.
Privileges
Every privilege, and the grant and revoke syntax that covers each one.
Database
Create and manage a database once you can reach the catalog.