How to Get the Most Out of Your Snowflake Trial- Part 2

In the first part of this series, we talked about the importance of having proper security in place from the start of your Snowflake trial to ensure that all activity and data within Snowflake is protected. The next milestone in your trial period is identifying your organization’s role hierarchy and setting up your users and their default warehouses. 

There is a bit of prep work for this step that can be done before the trial even begins. The key task is to identify the appropriate individuals within your organization that will step into the admin roles.

Role Hierarchy

These are default roles that exist within each Snowflake trial account. You may have different users for each of these roles, or you may have some users that act as multiple roles.

1. ACCOUNTADMIN

This role is at the top of the hierarchy. The account administrator has access to every section of the web interface and is the parent role to SYSADMIN and SECURITYADMIN. This role should be granted to one or two individuals in the organization.

2. SYSADMIN

This will be the default role of the person who starts the trial. This role should be used by those who are creating warehouses or databases. This role can grant privileges on objects to other roles.

3. PUBLIC

This is the default role of all users added to the account, unless otherwise specified. 

4. SECURITYADMIN

The user in this role has the ability to grant and modify any security privileges for objects, users and roles. They will also inherit the privileges of the USERADMIN.

5. USERADMIN

This role is able to create new users and new roles. They can also modify users and roles that they own.

Anyone with the SECURITYADMIN role can, of course, add additional custom roles using SQL or the web interface to suit more specific functions. Some that I see quite often include a REPORTING role that can be assigned to anyone that will be connecting from a data visualization or a business intelligence tool. If you plan to have your environment split between development and production, you could have a REPORT_DEV and a REPORT_PROD role that would give users access to those specific environments.

I would also add one or multiple ANALYST roles for those in different departments such as ANALYST_HR or ANALYST_FINANCE that may be accessing the account to run ad hoc queries or test data. There are a multitude of roles that could be added, it all depends on the different levels of access that you will need to provide to users.

When creating these roles, you should declare the parent role for each one. This, in turn, develops a role hierarchy which allows parent roles to inherit the privileges of the dependent role. It’s usually recommended that custom roles are granted to SYSADMIN.

Create Warehouses

The next step will take us to the “Warehouses” section of the interface to add any warehouses with specific functionality. Remember, virtual warehouses are the cluster of compute resources. You will be using these when executing SQL queries or making changes to tables. I prefer to have warehouses for specific functions so that I can determine which warehouses are using what credits, and how often different activities are actively using the warehouses.

I recommend starting with these warehouses:

1. LOADING_WH
2. DEVELOPING_WH
3. REPORTING_WH
4. COMPUTE_WH (default)

I always make sure to set my warehouses to an X-Small to begin with to save on credits. Once you begin executing queries or loading data, if you find it is super slow and painful, try boosting it up to a Small or Medium.

Create Users

If you were not using single sign-on and if you know which users will need access to the Snowflake account, now would be a great time to get their authentication set up. For some roles this can be done at various points in the implementation process, or even on an as-needed basis when users are requiring access. I would recommend having the users who will be assigned to any admin roles added so they can take ownership of those roles.

You can use an SQL query to add users to the account or you can use the web interface within the “Account” section. This process requires you to provide a username and password for each user. During this process, you should also identify the default settings for each user. This includes the default warehouse they should be using, the default namespace (database and schema), and the default role for this user. You can change these defaults at a later date using the ALTER USER command.

Stay tuned for the final part of this series, where we get your data loaded and provide access to your now existing users!

Explore More