User / Password authentication
Snowflake can be configured using basic user/password authentication as shown below.
my-snowflake-db:target: devoutputs:dev:type: snowflakeaccount: [account id]# User/password authuser: [username]password: [password]role: [user role]database: [database name]warehouse: [warehouse name]schema: [dbt schema]threads: [1 or more]client_session_keep_alive: Falsequery_tag: [anything]
Key Pair Authentication
To use key pair authentication, omit a
password and instead provide a
private_key_path and, optionally, a
private_key_passphrase in your target. Note: Versions of dbt before 0.16.0 required that private keys were encrypted and a
private_key_passphrase was provided. This behavior was changed in dbt v0.16.0.
my-snowflake-db:target: devoutputs:dev:type: snowflakeaccount: [account id]user: [username]role: [user role]# Keypair configprivate_key_path: [path/to/private.key]private_key_passphrase: [passphrase for the private key, if key is encrypted]database: [database name]warehouse: [warehouse name]schema: [dbt schema]threads: [1 or more]client_session_keep_alive: Falsequery_tag: [anything]
To use SSO authentication for Snowflake, omit a
password and instead supply an
authenticator config to your target.
authenticator can be one of 'externalbrowser' or a valid Okta URL.
Note: By default, every connection that dbt opens will require you to re-authenticate in a browser. The Snowflake connector package supports caching your session token, but it currently only supports Windows and Mac OS. See the Snowflake docs for how to enable this feature in your account.
my-snowflake-db:target: devoutputs:dev:type: snowflakeaccount: [account id]user: [username]role: [user role]# SSO configauthenticator: externalbrowserdatabase: [database name]warehouse: [warehouse name]schema: [dbt schema]threads: [between 1 and 8]client_session_keep_alive: Falsequery_tag: [anything]
The "base" configs for Snowflake targets are shown below. Note that you should also specify auth-related configs specific to the authentication method you are using as described above.
|account||Yes||The account to connect to as per Snowflake's documentation. See notes below|
|user||Yes||The user to log in as|
|database||Yes||The database that dbt should create models in|
|warehouse||Yes||The warehouse to use when building models|
|schema||Yes||The schema to build models into by default. Can be overridden with custom schemas|
|role||No (but recommended)||The role to assume when running queries as the specified user.|
|client_session_keep_alive||No||If provided, issue a periodic |
|threads||No||The number of concurrent models dbt should build. Set this to a higher number if using a bigger warehouse. Default=1|
|query_tag||No||A value with which to tag all queries, for later searching in QUERY_HISTORY view|
For AWS accounts in the default US West region, this will be something like
abc123 (without any other segments). For AWS accounts not in the default US West region and for GCP and Azure-based accounts, you also have to append the cloud platform, such as
azure, respectively (for example:
abc123.us-central1.gcp) See Snowflake's documentation for more information.
client_session_keep_alive feature is intended to keep Snowflake sessions alive beyond the typical 4 hour timeout limit. The snowflake-connector-python implementation of this feature can prevent processes that use it (read: dbt) from exiting in specific scenarios. If you encounter this in your deployment of dbt, please let us know in the GitHub issue, and work around it by disabling the keepalive.