Snowflake Structure and Core Vocabulary

Containers, from broadest to narrowest

A Snowflake environment becomes easy to navigate the moment you separate containers from the objects inside them. Every securable object lives somewhere, and that "somewhere" is a chain with a fixed order.

The customer organization is the top-most logical container. An organization contains account objects, an account contains databases, a database contains schemas, and a schema contains securable objects such as tables, views, functions, and stages.

Read the path from broadest to narrowest: organization, account, database, schema, object. A table is not a peer of a database, and a schema is not above an account. Exam options often scramble exactly two of these levels, so read the whole sequence before choosing.

What lives inside a schema

The schema is where the vocabulary stops being abstract. It is the named container, inside a database, that holds the objects you actually query and load into.

Tables, views, functions, and stages are all securable objects held in a schema. That is what makes the schema the right answer whenever a design has to keep a stage next to its tables and views in a single named container within one database.

The frequent confusions are worth naming:

The four words of access control

Four terms do most of the work in Snowflake security, and most beginner errors are simply two of them swapped.

A user is an identity recognized by Snowflake and can represent a person or a service. A securable object is an entity to which access can be granted, and access is denied unless a grant allows it. A role is an entity to which privileges can be granted, while a privilege defines a level of access to an object.

Note the default in that definition of a securable object: access is denied unless a grant allows it. Nothing is open by accident.

Roles: privileges on one side, users on the other

A role is the hinge of the usual RBAC model: privileges are granted to it, and it in turn is granted to users. It is not the only possible grantee, however. Snowflake also supports direct grants to users through user-based access control (UBAC). These privileges count only when ALL secondary roles are active in the session.

For example, Alice may receive a direct SELECT grant on the Sales table. That grant counts if ALL secondary roles are already active in her session. If they are not active, she can activate them with USE SECONDARY ROLES ALL.

That is why a role is neither a container nor a permission. It does not store databases or schemas, which live in the object hierarchy. And it is not itself a level of access such as SELECT, which is a privilege. It is the named bundle that collects privileges so they can be handed to people and services consistently.

A user can hold multiple roles and switch the active role in a session to perform different actions with different privilege sets. Switching the primary role is not by itself an isolation guarantee. A session acts with the aggregate privileges granted to its primary role and to any active secondary roles, so an analyst who wants only production rights in play must also control which secondary roles are active. Authorization for CREATE statements comes from the primary role alone.

The RBAC chain

Snowflake usually uses role-based access control, in which privileges are assigned to roles and roles are assigned to users. Say the chain out loud until it is automatic: grant privileges on securable objects to roles, then grant roles to users.

The value of that indirection is practical. When someone joins, changes team, or leaves, you change which roles they hold, not dozens of individual grants on individual tables. And when a new table appears, you grant on it once, to a role, and everyone who holds that role is covered.

The chain describes RBAC, not every authorization path. Users are identities rather than containers, but they can receive privileges directly through UBAC. Databases are securable containers, and privileges describe allowed actions on them.

Ownership belongs to a role

Ownership answers a different question from either hierarchy: not where this object lives, and not who may read it, but which role controls it.

Each securable object is owned by one role, which by default is the role used to create that object. Ownership is therefore a privilege relationship, not a statement that a user personally contains the object.

Two consequences follow, and both show up in questions:

• Ownership is singular. It is one role, not every user who can see the schema, and not the containing database or organization.
• Ownership follows the creating role, not the person who typed the statement. If you create a table while a different role is active, that role owns the result. Switching your active role before a CREATE is therefore a real design decision, not a formality.

Role hierarchy and privilege inheritance

Roles can be granted to other roles, creating a hierarchy in which roles higher in the hierarchy inherit privileges from roles below them.

Direction is everything here. Inheritance flows upward: the grantee role picks up what the granted role already had. Work an example through slowly.

Role C is granted to Role B. Role B is granted to Role A. Role A is assigned to a user.

So the user reaches C's privileges through A, not because A was granted to C, but because C was granted to B and B to A.

Keep the two maps apart. The object hierarchy answers where an object lives. The role hierarchy answers how privileges flow. They look similar on a diagram and behave nothing alike: a role never becomes a schema, and a schema never inherits anything.

Snowflake also ships a small set of system-defined roles that already sit in such a hierarchy (among them ACCOUNTADMIN, SECURITYADMIN, USERADMIN and SYSADMIN), plus PUBLIC, a pseudo-role automatically granted to every user and every role in the account. Custom roles are normally built into a hierarchy underneath them.

The session's active role

Signing in is not the same as being authorized. Every session carries an authority, and it is chosen by a documented rule.

Every active user session has exactly one current primary role and can also activate secondary roles. If a connection specifies a role already granted to the user, that role becomes the primary role. If no role is specified, Snowflake uses the user's default role, and PUBLIC when no default role has been set.

PUBLIC is the fallback precisely because it is granted to everyone; it is not a privileged administrator role, so a session that lands on it is usually a session that cannot do much.

The active role and its granted privileges determine which SQL actions the user can perform on objects. That single sentence explains a puzzle every beginner meets: an object is right there, in the right database and schema, and the query still fails.

Selecting an account, database, or schema identifies context. Selecting a role identifies authority. A correctly named object can still be unavailable when the active role lacks the necessary privileges, and when a user holds several roles, the first thing to check is which one is active and what it has been granted, on the object and on the containers around it.

Key takeaways

• Navigate containers as organization, account, database, schema, then securable object, and remember that the schema is what holds tables, views, functions, and stages.
• Users receive authority through roles and privileges; roles do not contain the data objects themselves. Grant privileges to roles, then roles to users.
• The current primary role is the session's central authorization context, and object ownership belongs to one role, by default the role that created the object.
• Two maps, never one: the object hierarchy says where an object lives, the role hierarchy says how privileges flow, upward from granted role to grantee.