Follow these steps to connect Looker to Snowflake:

1. Create a Looker user on Snowflake and provision access.
2. Set up a database connection in Looker.

Creating a Looker user on Snowflake

We recommend the following commands for creating the Looker user. Make sure to run each line individually.

Optionally, add in the ON FUTURE keyword to persist GRANT statements on newly created objects. We recommend running this for tables in all schemas that Looker will use so you are not required to re-run GRANT statements as new tables are created.

If you paste the above commands as a batch into the Snowflake connection panel, check the All Queries box to ensure all lines are run. By default, Snowflake runs only lines that are selected:

Adding the connection

Use the Looker interface to configure the database connection: In the Admin section of Looker, select Connections, and then select New Connection. See the Connecting Looker to your database documentation page for more information.

Enter the connection information in the required fields:

• Name: Give the connection a name. This is how the LookML model will reference the connection.
• Dialect: Select Snowflake.
• Host: Enter the Snowflake hostname. It will look like <account_name>.snowflakecomputing.com. Check Snowflake account name examples by region to make sure you use the right value for your deployment.
• Port: The default is 443.
• Database: Enter the default database to use,; this field is case-sensitive.
• Username and Password: Enter the username and password of the user who will connect to Looker.
• Schema: Enter the default schema.
• Persistent Derived Tables: Check this box to enable persistent derived tables (PDTs). This reveals additional PDT fields and the PDT Overrides column.
• Temp Database: If PDTs are enabled, set this field to a schema where the user has full privileges to create, drop, rename, and alter tables.
• Max Connections: This is the optional connection pool size. You can use the default value, or read more about this setting in the Max Connections section of the Connecting Looker to your database documentation page.
• Connection Pool Timeout: This is optional. Use the default value.
• Cost Estimate: Enables cost estimates for Explore queries and SQL Runner queries on the connection.
• Database Time Zone: The time zone your Snowflake database uses to store dates and times. The default is UTC. This is optional.
• Query Time Zone: The time zone you want your queries to display. For example, US Eastern (America – New York). This is optional.

• Additional Params: Add additional JDBC parameters from the Snowflake JDBC driver.

  • Add warehouse=<YOUR WAREHOUSE NAME>.

  • Additionally, by default, Looker will set the following Snowflake parameters on each session:

    • TIMESTAMP_TYPE_MAPPING=TIMESTAMP_LTZ
    • JDBC_TREAT_DECIMAL_AS_INT=FALSE
    • TIMESTAMP_INPUT_FORMAT=AUTO
    • AUTOCOMMIT=TRUE

    You can override each of these by setting an alternative value in the Additional Params field, for example: &AUTOCOMMIT=FALSE

Click on Test These Settings to verify that the connection to Snowflake is successful. See the Testing database connectivity documentation page for troubleshooting information.

Click Add Connection to save the connection.

Designating Snowflake warehouses on a per-group or per-user basis

You can use Looker user attributes to assign separate Snowflake warehouses to individual Looker users or groups. This is useful, for example, if you have users who require different levels of computing power. You can assign a warehouse with greater computing resources to just those users who need it, while assigning a warehouse with lesser resources to users with lesser needs.

To designate warehouses on a per-group or per-user basis:

1. Add the groups or users in Looker.

2. Define a user attribute to store the Snowflake warehouse names:

   

3. In the user attribute you just defined, assign the warehouse name values to the groups or users:

   

4. In the Additional Params field on the Connection Settings page, add the following, replacing snowflake_warehouse with the name of the user attribute you defined:

   warehouse={{ _user_attributes['snowflake_warehouse'] }}

   For example:

   

5. To test the individual connection settings, you can sudo as a user to whom you assigned a warehouse name value.

You can see more detailed instructions for this procedure on the Red Pill Analytics blog.

Snowflake’s autosuspend feature

Snowflake warehouses have an autosuspend feature that is enabled by default. After a specified period, the warehouse will autosuspend. If the warehouse is suspended, all queries produce an error. This error is not visible via dashboards (no data is normally shown), but it is visible when querying with the Explore page.

Snowflake also has an autoresume feature that will resume the warehouse when it is queried. However, resuming the warehouse can take up to five minutes, causing queries to hang for five minutes before returning. These features can be configured on the Warehouses tab:

PDT support

For persistent derived table support, create a Snowflake user account for PDTs that has write access to your database and the default schema. On the Looker Connections Settings page, check the Persistent Derived Tables box. Then, in the PDT Overrides column, enter the username and password of the PDT user. See the Connecting Looker to your database documentation page for more information.

PDTs are not supported for Snowflake connections that use OAuth.

For Snowflake connections, Looker sets the value for the AUTOCOMMIT parameter to TRUE (which is Snowflake’s default value). AUTOCOMMIT is required for SQL commands that Looker runs to maintain its PDT registration system.

Configuring OAuth for Snowflake connections

Looker supports OAuth for Snowflake connections, meaning that each Looker user authenticates in to Snowflake and authorizes Looker to run queries on the database with their own Snowflake user account.

OAuth lets database administrators:

• Audit which Looker users are running queries against the database
• Enforce role-based access controls using Snowflake permissions
• Use OAuth tokens for all processes and actions that access Snowflake, instead of embedding Snowflake IDs and passwords in multiple places
• Revoke authorization for a given user through Snowflake

With Snowflake connections that use OAuth, users must log in again periodically when their OAuth tokens expire. The duration of validity for Snowflake OAuth tokens is set through Snowflake itself.

Note the following for Snowflake with OAuth:

• If a user lets their Snowflake token expire, any schedules or alerts that they own will be affected. To guard against this, Looker will send a notification email to the owner of each schedule and each alert before the current active Snowflake OAuth token expires. Looker will send these notifications emails 14 days, 7 days, and 1 day before the token expires. The user can go to their Looker user page to reauthorize Looker to the database and avoid any interruption to their schedules and alerts. See the Personalizing user account settings documentation page for details.
• Since Snowflake connections that use OAuth are “per user,” caching policies are also per user, and not just per query. So instead of using cached results whenever the same query is run within the caching period, Looker will use cached results only if the same user has run the same query within the caching period. For further information on caching, see the Caching queries and rebuilding PDTs with datagroups documentation page.
• When using OAuth, you cannot switch to different roles in the Snowflake user account. As described in the Snowflake documentation, Snowflake uses the default role of the Snowflake user’s account, unless the default role is ACCOUNTADMIN or SECURITYADMIN. Because these roles are blocked for OAuth, Snowflake will instead use the PUBLIC role. See the Snowflake documentation for information.
• Persistent derived tables (PDTs) are not supported for Snowflake connections with OAuth.
• Admins, when they sudo as another user, will use that user’s OAuth access token. If the user’s access token is expired, the admin will not be able to have a new token created on behalf of the sudoed user; the user will have to log in to Snowflake and reauthorize Looker. See the Users documentation page for information on using the sudo command.

Configuring a Snowflake database for OAuth with Looker

To create a Snowflake connection to Looker using OAuth, you must set up the OAuth integration in Snowflake. This requires a Snowflake user account with ACCOUNTADMIN permission.

1. Run the following command in Snowflake:

   CREATE SECURITY INTEGRATION LOOKER TYPE = OAUTH ENABLED = TRUE OAUTH_CLIENT = LOOKER OAUTH_REDIRECT_URI = 'https://<looker_hostname>/external_oauth/redirect';

   Where <looker_hostname> is the hostname of your Looker instance.

2. Get the OAuth client ID and secret by running the following command:

   SELECT SYSTEM$SHOW_OAUTH_CLIENT_SECRETS('LOOKER');

   The response will have an OAUTH_CLIENT_ID and OAUTH_CLIENT_SECRET that you will need later in this procedure.

3. In Looker, create a new connection to your Snowflake warehouse, as described on the Connecting Looker to your database documentation page. When creating the new connection, check the Use OAuth checkbox. When you select Use OAuth, you will see the OAuth Client ID and OAuth Client Secret fields:

   

4. Paste in the OAUTH_CLIENT_ID and OAUTH_CLIENT_SECRET values from Step 2.

5. Complete the rest of the procedure for Connecting Looker to your database.

Once you configure Looker’s connection to your database, you can test the connection itself by doing either of the following:

• Click the Test These Settings button at the bottom of the Connections Settings page, as described on the Connecting Looker to your database documentation page.
• Click the Test button by the connection’s listing on the Connections admin page, as described on the Connections documentation page.

Beyond that, you can test the connection and deploy it on a model by doing the following:

1. In Looker, go into Development Mode.
2. Navigate to the project files for a Looker project that uses your Snowflake connection.
3. Open a model file and replace the model’s connection value with the name of the new Snowflake connection, then save the model file.
4. Open one of the model’s Explores or dashboards and run a query. When you try to run a query, Looker will prompt you to log in to Snowflake.
5. Follow the login prompts for Snowflake and enter your Snowflake credentials.

Once you successfully log in to Snowflake, Looker will return you back to your query. If your query runs correctly, you can commit the new connection value and deploy your changes to production.

Signing in to Snowflake to run queries

Once the Snowflake connection is set up for OAuth, users will be prompted to log in to Snowflake before running queries. This includes queries from Explores, dashboards, Looks, and SQL Runner. Here’s an example Explore that uses a Snowflake connection for which the user must log in:

Users can also log in to Snowflake from the OAuth Connection Credentials section on their Account page.

To log in to your Snowflake account via Looker:

1. Select Account from the user menu.
2. Scroll down to the OAuth Connection Credentials section and click the Log In button for the desired Snowflake database.
3. Enter your Snowflake credentials through Snowflake’s interface and click Log In.
4. Click Allow to give Looker access to your Snowflake account.

Once you log in to Snowflake through Looker, you can log out or reauthorize your credentials at any time through your Account page, as described on the Personalizing your user account documentation page.

Feature support

For Looker to support some features, your database dialect must also support them.

In Looker 22.6, Snowflake supports the following Looker features:

Next steps

After you have connected your database to Looker, configure sign-in options for your users.