Snowflake Object Hierarchy
1. Snowflake Object Hierarchy
Welcome back. Now let's look at how Snowflake organizes everything inside it. Understanding the object hierarchy is one of those things that makes everything else click: querying, access control, data loading. It all maps back to this structure.2. Understanding the Object Hierarchy
Snowflake organizes everything into five levels and the best way to understand it is to build it up from the outside in. The organization level is the outermost container. Most teams won't interact with it directly day to day, but it's where cross-account replication and centralized billing are managed. It can group multiple Snowflake accounts together. This is useful for enterprises managing several environments or regions.3. Understanding the Object Hierarchy
Directly below it, the account. This is your Snowflake environment: tied to a specific cloud provider, a specific region, and a specific edition. When someone says "our Snowflake account," this is what they mean. Everything below it sits within this boundary.4. Understanding the Object Hierarchy
Inside the account live six types of objects: users, roles, databases, virtual warehouses, resource monitors, and integrations. These exist across your entire environment: not within a specific database.5. Understanding the Object Hierarchy
Databases sit inside the account and act as logical containers. Inside each database, schemas organize your objects. A database named ANALYTICS might have schemas called RAW, STAGING, and MARTS - each holding tables and views at a different stage of transformation.6. Understanding the Object Hierarchy
And at the bottom, the objects themselves - tables, views, UDFs, and more. Everything in Snowflake lives somewhere in this hierarchy, and understanding which level an object belongs to is what makes querying, permissions, and data loading click.7. Account-level vs Database-level Objects
Remember, not all objects sit inside a database. Some will live at the account level such as users, roles, warehouses, and integrations exist across your entire Snowflake environment, not inside any specific database. Database-level objects are the ones you're probably most familiar with: tables, views, stages, UDFs and stored procedures. The distinction matters because access control works differently depending on where an object lives. A warehouse is shared across databases, whereas a table belongs to exactly one schema.8. Context
Before you run any query in Snowflake, four things need to be set: your role, your warehouse, your database, and your schema. You can set them using SQL USE statements: USE ROLE, USE WAREHOUSE, USE DATABASE, and USE SCHEMA. At Snowy Peak, a data engineer sets their role to ANALYST, their warehouse to COMPUTE_WH, and their database and schema to the ANALYTICS layer. Everything that follows runs in that context You can check what's currently set at any point using context functions: CURRENT_ROLE, CURRENT_WAREHOUSE, CURRENT_DATABASE, and CURRENT_SCHEMA. Run them in a SELECT and you'll see exactly what session you're operating in.9. Session Variables
Beyond context, there are two more tools that live at the session level. Session variables let you store and reuse values within a script. Set one with the SET function, for example, SET min_users = 100 then reference it anywhere in that session using dollar sign min_users.10. Parameter hierarchy: Account Parameters
Parameters are named settings that control how Snowflake behaves, and they fall into four types each with its own override chain. Account parameters sit at the top and can't be overridden. Whatever is set at the account level is what applies, things like PERIODIC_DATA_REKEYING.11. Session Parameters
Session parameters work differently. The account sets a default, an administrator can override it for a specific user, and the user can override it again within their active session. The lowest level at which the parameter is set wins.12. Virtual Warehouse Parameters
Virtual warehouse parameters follow a simpler two-level chain: account default, then overridden at the warehouse itself. STATEMENT_TIMEOUT_IN_SECONDS is the classic one — you might want a tighter timeout on your dashboard warehouse than the account default allows.13. Table Parameters
Finally, database, schema, and table parameters cascade down through the object hierarchy. Set a default at the account level, override it at the database, narrow it further at the schema, and override it again on a specific table. DATA_RETENTION_TIME_IN_DAYS works this way, your account might default to one day, but your more important billing tables get thirty. The rule across all four types is the same: the lowest level at which the parameter is set will be used, and that value wins.14. Let's practice!
Time to put what you’ve learned into practice.Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.