Connect Snowflake Fusion compatible

note

dbt connections and credentials inherit the permissions of the accounts configured. You can customize roles and associated permissions in Snowflake to fit your company's requirements and fine-tune access to database objects in your account.

Refer to Snowflake permissions for more information about customizing roles in Snowflake.

Warehouse permissions for Fusion

The Snowflake user or service account that dbt Fusion engine connects as must be able to run dbt workloads (queries, metadata, and typical materializations). Grant privileges through a Snowflake role assigned to that user.

Required Snowflake objects

Before connecting, these objects must exist:

Object	Purpose
Account	Your Snowflake account identifier
User	Service account or user for Fusion
Role	Role assigned to the user with required privileges
Warehouse	Virtual warehouse for compute
Database	Target database or databases for dbt models
Schema	Target schema or schemas within the database

Loading table...

Core operations

The following are required permissions for fundamental dbt operations:

Permission	Object	Purpose
USAGE	Warehouse	Execute queries
USAGE	Database	Access the database
USAGE	Schema	Access schemas
SELECT	Tables or views	Read existing data and sources
CREATE TABLE	Schema	Create models materialized as tables
CREATE VIEW	Schema	Create models materialized as views
INSERT	Tables	Load data into tables
UPDATE	Tables	Incremental model updates
DELETE	Tables	Incremental models using delete and insert
TRUNCATE	Tables	Full refresh of incremental models
DROP	Tables or views	Replace existing objects

Loading table...

Metadata operations

The following are required permissions for dbt metadata operations:

Permission	Object	Purpose
USAGE	INFORMATION_SCHEMA	Query table and column metadata
DESCRIBE TABLE	Tables	Get schema information
SHOW OBJECTS	Schema	List relations in schema
SHOW USER FUNCTIONS	Schema	Discover UDFs (if used)

Loading table...

Schema and database management

The following are conditional permissions for schema and database management:

Permission	Object	When required
CREATE SCHEMA	Database	Fusion should auto-create schemas
CREATE DATABASE	Account	Fusion should auto-create databases

Loading table...

Advanced features

The following are optional permissions for advanced features:

Permission	Object	Feature
CREATE STAGE	Schema	File staging for seeds or snapshots
CREATE FILE FORMAT	Schema	Custom file formats
CREATE SEQUENCE	Schema	Sequences
EXECUTE TASK	Schema	Snowflake tasks

Loading table...

For role examples in Snowflake, see Snowflake permissions.

Snowflake column size change

Snowflake plans to increase the default column size for string and binary data types in May 2026. dbt-snowflake versions below v1.10.6 may fail to build certain incremental models when this change is deployed.

 Assess impact and required actions

If you're using a dbt-snowflake version below v1.10.6 or have not yet migrated to a release track in the dbt platform, your adapter version is incompatible with this change and may fail to build incremental models that meet both of the following conditions:

• Contain string columns with collation defined
• Use the on_schema_change='sync_all_columns' config

To check whether this change affects your project, run the following list command:

dbt ls -s config.materialized:incremental,config.on_schema_change:sync_all_columns --resource-type model

• If the command returns No nodes selected!, no action is required.

• If the command returns one or more models (for example, Found 1000 models, 644 macros), you may be impacted if those models have string columns that don't specify a width. In that case, upgrade to a version that includes the fix:

  • dbt Core: dbt-snowflake v1.10.6 or later. For upgrade instructions, see Upgrade adapters.
  • dbt platform: Any release track (Latest, Compatible, Extended, or Fallback).
  • dbt Fusion engine: v2.0.0-preview.147 or higher.

  This ensures your incremental models can safely handle schema changes while maintaining required collation settings.

The following fields are required when creating a Snowflake connection:

Field	Description	Examples
Account	The Snowflake account to connect to. Take a look here to determine what the account field should look like based on your region.	✅ db5261993 or db5261993.east-us-2.azure   ❌ db5261993.eu-central-1.snowflakecomputing.com
Role	A mandatory field indicating what role should be assumed after connecting to Snowflake	transformer
Database	The logical database to connect to and run queries against.	analytics
Warehouse	The virtual warehouse to use for running queries.	transforming

Loading table...

Authentication methods

This section describes the different authentication methods for connecting dbt to Snowflake. Configure Deployment environment (Production, Staging, General) credentials globally in the Connections area of Account settings. Individual users configure their development credentials in the Credentials area of their user profile.

Username and password with MFA

Snowflake authentication

Starting November 2025, Snowflake will phase out single-factor password authentication, and multi-factor authentication (MFA) will be enforced.

MFA will be required for all Username / Password authentication.

To continue using key pair authentication, users should update any deployment environments currently using Username / Password by November 2025.

Refer to Snowflake's blog post for more information.

Snowflake MFA plan availability

Snowflake's MFA is available on all plan types.

Available in: Development environments

The Username / Password auth method is the simplest way to authenticate Development credentials in a dbt project. Simply enter your Snowflake username (specifically, the login_name) and the corresponding user's Snowflake password to authenticate dbt to run queries against Snowflake on behalf of a Snowflake user.

Username / Password authentication is not supported for deployment credentials because MFA is required. In deployment environments, use keypair authentication instead.

Note: The Schema* field in the Developer Credentials section is required.

Snowflake username/password authentication

Prerequisites:

• A development environment in a dbt project
• The Duo authentication app
• Admin access to Snowflake (if MFA settings haven't already been applied to the account)
• Admin (write) access to dbt environments

MFA is required by Snowflake for all Username / Password logins. Snowflake's MFA support is powered by the Duo Security service.

• In dbt, set the following extended attribute in the development environment General settings page, under the Extended attributes section:

  authenticator: username_password_mfa

• To reduce the number of user prompts when connecting to Snowflake with MFA, enable token caching in Snowflake.

• Optionally, if users miss prompts and their Snowflake accounts get locked, you can prevent automatic retries by adding the following in the same Extended attributes section:

  connect_retries: 0

Configure the MFA username and password, and connect_retries in the development environment settings.

Key pair

Available in: Development environments, Deployment environments

The Keypair auth method uses Snowflake's Key Pair Authentication to authenticate Development or Deployment credentials for a dbt project.

1. After generating an encrypted key pair, be sure to set the rsa_public_key for the Snowflake user to authenticate in dbt:

   alter user jsmith set rsa_public_key='MIIBIjANBgkqh...';   

2. Finally, set the Private Key and Private Key Passphrase fields in the Credentials page to finish configuring dbt to authenticate with Snowflake using a key pair.

   • Note: Unencrypted private keys are permitted. Use a passphrase only if needed. dbt can specify a private_key directly as a string instead of a private_key_path. This private_key string can be in either Base64-encoded DER format, representing the key bytes, or in plain-text PEM format. Refer to Snowflake documentation for more info on how they generate the key.
   • Specifying a private key using an environment variable (for example, {{ env_var('DBT_PRIVATE_KEY') }}) is not supported.

3. To successfully fill in the Private Key field, you must include commented lines. If you receive a Could not deserialize key data or JWT token error, refer to Troubleshooting for more info.

Example:

-----BEGIN ENCRYPTED PRIVATE KEY-----
< encrypted private key contents here - line 1 >
< encrypted private key contents here - line 2 >
< ... >
-----END ENCRYPTED PRIVATE KEY-----

Snowflake keypair authentication

Fusion key pair

We recommend using PKCS#8 format with AES-256 encryption for key pair authentication with Fusion. Fusion doesn't support legacy 3DES encryption or headerless key formats. Using older key formats may cause authentication failures.

If you encounter the Key is PKCS#1 (RSA private key). Snowflake requires PKCS#8 error, then your private key is in the wrong format. You have two options:

• (Recommended fix) Re-export your key with modern encryption:

  # Convert to PKCS#8 with AES-256 encryption
  openssl genrsa 2048 | openssl pkcs8 -topk8 -v2 aes-256-cbc -inform PEM -out rsa_key.p8

• (Temporary workaround) Add the BEGIN header and END footer to your PEM body:

  -----BEGIN ENCRYPTED PRIVATE KEY-----
  < Your existing encrypted private key contents >
  -----END ENCRYPTED PRIVATE KEY-----

Snowflake OAuth

Available in: Development environments, Enterprise-tier plans only

The OAuth auth method permits dbt to run development queries on behalf of a Snowflake user without the configuration of Snowflake password in dbt.

For more information on configuring a Snowflake OAuth connection in dbt, please see the docs on setting up Snowflake OAuth.

Configuring Snowflake OAuth connection

Configuration

To learn how to optimize performance with data platform-specific configurations in dbt, refer to Snowflake-specific configuration.

Custom domain URL

To connect to Snowflake through a custom domain (vanity URL) instead of the account locator, use extended attributes to configure the host parameter with the custom domain:

host: https://custom_domain_to_snowflake.com

This configuration may conflict with Snowflake OAuth when used with PrivateLink. IF users can't reach Snowflake authentication servers from a networking standpoint, please contact dbt Support to find a workaround with this architecture.

Troubleshooting

If you're receiving a Could not deserialize key data or JWT token error, refer to the following causes and solutions:

 Error: `Could not deserialize key data`

Possible cause and solution for the error "Could not deserialize key data" in dbt.

• This could be because of mistakes like not copying correctly, missing dashes, or leaving out commented lines.

Solution:

• You can copy the key from its source and paste it into a text editor to verify it before using it in dbt.

 Error: `JWT token`

Possible cause and solution for the error "JWT token" in dbt.

• This could be a transient issue between Snowflake and dbt. When connecting to Snowflake, dbt gets a JWT token valid for only 60 seconds. If there's no response from Snowflake within this time, you might see a JWT token is invalid error in dbt.
• The public key was not entered correctly in Snowflake.

Solutions

• dbt needs to retry connections to Snowflake.
• Confirm and enter Snowflake's public key correctly. Additionally, you can reach out to Snowflake for help or refer to this Snowflake doc for more info: Key-Based Authentication Failed with JWT token is invalid Error.

Was this page helpful?

Privacy policyCreate a GitHub issue

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.