Follow these steps to connect Looker to Snowflake:
- Create a Looker user on Snowflake and provision access.
- Set up a database connection in Looker.
Encrypting network traffic
It is a best practice to encrypt network traffic between the Looker application and your database. Consider one of the options described on the Enabling secure database access documentation page.
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 persistGRANT
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-runGRANT
statements as new tables are created.
-- change role to ACCOUNTADMIN
use role ACCOUNTADMIN;
-- create role for looker
create role if not exists looker_role;
grant role looker_role to role SYSADMIN;
-- Note that we are not making the looker_role a SYSADMIN,
-- but rather granting users with the SYSADMIN role to modify the looker_role
-- create a user for looker
create user if not exists looker_user
password = '<enter password here>';
grant role looker_role to user looker_user;
alter user looker_user
set default_role = looker_role
default_warehouse = 'looker_wh';
-- change role
use role SYSADMIN;
-- create a warehouse for looker (optional)
create warehouse if not exists looker_wh
-- set the size based on your dataset
warehouse_size = medium
warehouse_type = standard
auto_suspend = 1800
auto_resume = true
initially_suspended = true;
grant all privileges
on warehouse looker_wh
to role looker_role;
-- grant read only database access (repeat for all database/schemas)
grant usage on database <database> to role looker_role;
grant usage on schema <database>.<schema> to role looker_role;
-- rerun the following any time a table is added to the schema
grant select on all tables in schema <database>.<schema> to role looker_role;
-- or
grant select on future tables in schema <database>.<schema> to role looker_role;
-- create schema for looker to write back to
use database <database>;
create schema if not exists looker_scratch;
use role ACCOUNTADMIN;
grant ownership on schema looker_scratch to role SYSADMIN revoke current grants;
grant all on schema looker_scratch to role looker_role;
If you paste the previous commands as a batch into the Snowflake connection panel, select the All Queries checkbox to ensure that all lines are run. By default, Snowflake runs only the lines that are selected.
Creating the Looker connection to your database
In the Admin section of Looker, select Connections, and then click Add Connection.
Fill out the connection details. The majority of the settings are common to most database dialects. See the Connecting Looker to your database documentation page for information. Some of the settings are described next:
- 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.
- Schema: Enter the default schema.
- Authentication: Select Database Account or OAuth:
- Use Database Account to specify the Username and Password of the Snowflake user account that will be used to connect to Looker.
- Use OAuth if you want to configure OAuth for the connection.
- Enable PDTs: Use this toggle to enable persistent derived tables (PDTs). Enabling PDTs reveals additional PDT fields and the PDT Overrides section for the connection.
- 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 per node: This setting can be left at the default value initially. Read more about this setting in the Max connections per node section of the Connecting Looker to your database documentation page.
- Cost Estimate: Enables cost estimates for Explore queries, cost estimates for SQL Runner queries, and computation savings estimates for aggregate awareness 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 JDBC parameters: 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 parameters by setting an alternative value in the Additional JDBC parameters field, for example:
&AUTOCOMMIT=FALSE
- Add
To verify that the connection is successful, click Test. See the Testing database connectivity documentation page for troubleshooting information.
To save these settings, click Connect.
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:
- Add the groups or users in Looker.
Define a user attribute in Looker where the Snowflake warehouse names will be stored. You can give this attribute any name, such as
snowflake_wh
.In the user attribute you just defined, assign the warehouse name values to the groups or users.
In the Additional JDBC parameters field on the Connection Settings page, add the following, replacing
snowflake_warehouse
with the name of the user attribute that you defined:warehouse={{ _user_attributes['snowflake_warehouse'] }}
For example:
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 on dashboards (no data is normally shown), but it is visible when querying with the Explore page.
Snowflake also has an auto-resume 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 cannot be configured in Looker. Enable these features on the Warehouses tab in the Snowflake UI.
PDT support
For persistent derived table support, create a Snowflake user account for PDTs that has write access to your database and the temp schema that Looker will use to create PDTs. On the Looker Connections Settings page, in the Persistent Derived Tables (PDTs) section, turn on the Enable PDTs toggle. Then, in the Temp database field, enter the name of the temp schema that Looker will use to create PDTs. Next, in the PDT Overrides section, 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.
- Because Snowflake connections that use OAuth are "per user," caching policies are also per user and not just per query. This means that, 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 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.
Run the following command in Snowflake, where
<looker_hostname>
is the hostname of your Looker instance:CREATE SECURITY INTEGRATION LOOKER TYPE = OAUTH ENABLED = TRUE OAUTH_CLIENT = LOOKER OAUTH_REDIRECT_URI = 'https://<looker_hostname>/external_oauth/redirect';
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
andOAUTH_CLIENT_SECRET
that you will need later in this procedure.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, select the OAuth option in the Authentication field. When you select the OAuth option, Looker displays the OAuth Client ID and OAuth Client Secret fields.
Paste in the
OAUTH_CLIENT_ID
andOAUTH_CLIENT_SECRET
values that you got from your database earlier in this procedure.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:
- Select the Test button at the bottom of the Connections Settings page, as described on the Connecting Looker to your database documentation page.
- Select 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:
- In Looker, go into Development Mode.
- Navigate to the project files for a Looker project that uses your Snowflake connection.
- Open a model file and replace the model's
connection
value with the name of the new Snowflake connection, and then save the model file. - 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.
- 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.
Users can also log in to Snowflake from the OAuth Connection Credentials section on their Account page.
To log in to your Snowflake account using Looker:
- Click the Looker user menu.
- Select Account.
- In the Account page, scroll down to the OAuth Connection Credentials section, and select the Log In button for the desired Snowflake database.
This will display a Snowflake login pop-up window. Enter your Snowflake credentials and select Log In, and then select 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.
Snowflake supports the following features as of Looker 24.8:
Feature | Supported? |
---|---|
Support Level | Supported |
Looker (Google Cloud core) | Yes |
Symmetric Aggregates | Yes |
Derived Tables | Yes |
Persistent SQL Derived Tables | Yes |
Persistent Native Derived Tables | Yes |
Stable Views | Yes |
Query Killing | Yes |
SQL-based Pivots | Yes |
Timezones | Yes |
SSL | Yes |
Subtotals | Yes |
JDBC Additional Params | Yes |
Case Sensitive | Yes |
Location Type | Yes |
List Type | Yes |
Percentile | Yes |
Distinct Percentile | No |
SQL Runner Show Processes | No |
SQL Runner Describe Table | Yes |
SQL Runner Show Indexes | No |
SQL Runner Select 10 | Yes |
SQL Runner Count | Yes |
SQL Explain | Yes |
Oauth Credentials | Yes |
Context Comments | Yes |
Connection Pooling | Yes |
HLL Sketches | Yes |
Aggregate Awareness | Yes |
Incremental PDTs | Yes |
Milliseconds | Yes |
Microseconds | Yes |
Materialized Views | No |
Approximate Count Distinct | No |
Next steps
After you have connected your database to Looker, configure sign-in options for your users.