About the Snowflake Connector
The Snowflake Connector lets you query data in your Snowflake data warehouse directly from Perplexity. You can search and combine information across your Snowflake databases, your other connected apps, and the web — without writing SQL by hand or switching to the Snowflake console.
It is available on Perplexity Pro, Perplexity Max, Enterprise Pro, and Enterprise Max. Connecting Snowflake is done per user — no one else in your organization can query your data unless you sync it to a shared Project.
This guide covers how the connector works, how to choose an authentication method, how to configure roles and read-only access, and a step-by-step setup. If you just want the fastest path: most organizations should use User OAuth — jump to Setup guide.
What the connector can access
Once enabled, the connector securely connects to your Snowflake account and lets you search across the databases, schemas, tables, and views you are authorized to see. When your Snowflake data changes, the connector reflects those changes automatically on your next query.
Supported data objects:
Tables
Views and materialized views
Schemas
Databases
Structured data (CSV-, JSON-, and Parquet-backed tables)
Unstructured data (images, audio, and video stored in Snowflake stages) is not supported.
Choosing an authentication method
Snowflake authentication has two independent dimensions: who the queries run as (the identity) and how that identity proves itself (the credential). Perplexity ships two connectors in the directory, each matched to a recommended combination:
Snowflake (User OAuth) — each Perplexity user signs in with their own Snowflake account (
TYPE = PERSON) via OAuth. Recommended for most organizations.Snowflake — all Perplexity users query through a single shared service account (
TYPE = SERVICE) using a key pair. Use this when your end users do not have individual Snowflake accounts.
Recommended: User OAuth
With User OAuth, each person authenticates with their own credentials, queries run under their native Snowflake permissions, and you get a clear per-user audit trail — no shared service account and no need to recreate your role-based access control (RBAC) inside Perplexity. This also matches Snowflake’s own direction: its managed MCP server only supports OAuth 2.0 today.
Note: With OAuth, the access token is bound to a single primary role at sign-in — the user’s DEFAULT_ROLE. To make sure users can reach everything they have been granted, configure secondary roles (see User OAuth role configuration).
Fallback: service account (key pair)
A shared service account (TYPE = SERVICE + key pair) is appropriate when:
Your end users do not have individual Snowflake accounts (for example, business users who query through Perplexity but have no direct Snowflake access).
You want all Perplexity queries to run under a single shared identity for simpler auditing.
You are setting up an internal or test environment where per-user identity is not required.
Configure the service account with a dedicated, narrowly-scoped role — see Service account role configuration.
A note on Programmatic Access Tokens (PATs): Snowflake also supports PAT credentials, and the connector accepts them. We do not recommend PAT for new setups — tokens expire on a short schedule and are hard-bound to a single role at creation time, so we use a key pair in the examples throughout this guide. If you must use a PAT, set ROLE_RESTRICTION to your dedicated Perplexity role at creation time.
Configuring roles and access
User OAuth role configuration
An OAuth session opens with the user’s DEFAULT_ROLE as the primary role; role switching within a session is not supported and Perplexity does not show a role picker. So whatever each user has set for DEFAULT_ROLE and DEFAULT_SECONDARY_ROLES is exactly what their Perplexity session uses.
Set this once, at the security integration level:
OAUTH_USE_SECONDARY_ROLES = IMPLICIT
Snowflake’s default for this parameter is NONE, which means OAuth sessions open with only the primary role active. Setting it to IMPLICIT tells Snowflake to also activate each user’s DEFAULT_SECONDARY_ROLES automatically. Without it, users see only data reachable through their DEFAULT_ROLE — rarely what you want.
Then handle one of two cases:
Case A — users already have role defaults. If your users’ DEFAULT_ROLE and DEFAULT_SECONDARY_ROLES are already set the way you want, do nothing else. The IMPLICIT setting is enough — each user’s existing defaults are what their Perplexity session uses.
Case B — users do not yet have role defaults. Give each session the union of all roles granted to that user by setting DEFAULT_ROLE to PUBLIC and DEFAULT_SECONDARY_ROLES to ALL:
ALTER USER <username> SET DEFAULT_ROLE = PUBLIC, DEFAULT_SECONDARY_ROLES = (‘ALL’);
Note: Since Snowflake’s August 2024 change, DEFAULT_SECONDARY_ROLES = (‘ALL’) is the default for newly created users, so many orgs already have this set. Run DESC USER <username> to check before changing anything.
Service account role configuration
A service account is a single dedicated user that runs under one specific role — typically PERPLEXITY_ROLE. The PUBLIC + (‘ALL’) pattern used for OAuth does not apply here. Instead, set the service user’s DEFAULT_ROLE to your dedicated role and grant that role only the privileges Perplexity needs. This follows Snowflake’s service account best practices.
The full SQL for creating this user is in the Setup guide below.
(Optional) Restricting which roles can be used via OAuth
To limit which Snowflake roles users can authenticate into through the Perplexity OAuth integration, scope it at the security integration level:
PRE_AUTHORIZED_ROLES_LIST— an allowlist of roles permitted through this integration.BLOCKED_ROLES_LIST— a denylist of roles blocked from this integration.
ALTER SECURITY INTEGRATION PERPLEXITY_OAUTH
SET PRE_AUTHORIZED_ROLES_LIST = (‘ANALYST_ROLE’, ‘READ_ONLY_ROLE’);
Use this to keep sensitive roles (for example ACCOUNTADMIN) out of the OAuth flow entirely.
Controlling what Perplexity can do
The connector executes SQL through a tool surface (sourced from the Merge Snowflake connector). The Snowflake (User OAuth) connector exposes granular, named tools — including a dedicated read-only query tool (execute_sql_readonly) that only accepts SELECT, WITH, SHOW, DESCRIBE, EXPLAIN, VALUES, and LIST, and rejects DDL/DML and multi-statement input. The service-account Snowflake connector exposes a general execute_sql tool that accepts arbitrary SQL, including DDL and DML.
The authoritative control is Snowflake RBAC. No matter which tool is invoked, queries run under the role your configuration allows, so enforcing read-only at the Snowflake role level is the reliable backstop — and it is the only enforcement boundary on the service-account connector.
Recommended pattern — enforce read-only with a dedicated role. Provision a role such as PERPLEXITY_READ_ONLY that grants only USAGE and SELECT on the databases, schemas, and tables you want Perplexity to query, and does not grant INSERT, UPDATE, DELETE, CREATE, DROP, OWNERSHIP, or warehouse MODIFY. Then make sure users authenticate into that role:
Set it as the user’s
DEFAULT_ROLE, orScope the OAuth integration with
PRE_AUTHORIZED_ROLES_LISTand/or exclude write-capable roles withBLOCKED_ROLES_LIST(see Restricting which roles can be used via OAuth).
With RBAC configured this way, Snowflake rejects any write Perplexity attempts, regardless of which tool is called.
Note: The connector settings include a Tool permissions panel listing available tools. On the Snowflake (User OAuth) connector you can narrow which tools are exposed — for a read-only setup, enable only the read tools (for example execute_sql_readonly, list_*, describe_*, get_*) to keep write/DDL tools off the surface. Treat this as defense-in-depth, not the authoritative boundary: Snowflake RBAC (above) is what reliably enforces access.
Privacy and data security
When connected, the Snowflake Connector can perform the following actions on your behalf:
Execute SQL queries on your Snowflake data
Query Cortex Search and Cortex Analyst
Run custom UDFs and stored procedures
If you revoke access or remove a role in Snowflake, that data is immediately inaccessible from Perplexity. If you disconnect Snowflake in Perplexity, you can choose whether to keep or delete any cached data.
Enterprise-grade security and control
For Enterprise organizations, Perplexity offers SOC 2 Type II certification, end-to-end encryption, strict data privacy measures, and granular user access controls. Your Snowflake data is never used for AI training.
Connecting Snowflake is done per user — no one else in your organization can query your data. However, if you sync data to a shared Project, anyone with access to that Project can search it.
Organization admins can enable or disable the connector for all users from the Permissions screen in Organization Settings. Read/write enforcement is handled at the Snowflake role level (see Controlling what Perplexity can do).
Setup guide
Choose the path that matches your authentication method:
User OAuth (recommended): An org admin configures the OAuth app once, then users sign in individually. Skip straight to Connect Snowflake to Perplexity — the SQL in steps 1–6 is for service-account setups only.
Service account (key pair): Run the SQL setup in steps 1–6, then connect in step 7.
Prerequisites
ACCOUNTADMINrole (or a role withCREATE USERandGRANTprivileges)OpenSSL installed locally (pre-installed on macOS) — service-account setups only
Step 1: Generate a key pair (service account)
From your terminal, generate an RSA private key:
openssl genrsa 2048 | openssl pkcs8 -topk8 -inform PEM -out snowflake_computer_key.p8 -nocrypt
Then generate the matching public key:
openssl rsa -in snowflake_computer_key.p8 -pubout -out snowflake_computer_key.pub
Step 2: Create a role and warehouse
USE ROLE ACCOUNTADMIN;
— Create a dedicated role
CREATE ROLE IF NOT EXISTS PERPLEXITY_ROLE
COMMENT = ‘Role for Perplexity service account’;
— Create a warehouse (or use an existing one)
CREATE WAREHOUSE IF NOT EXISTS PERPLEXITY_WAREHOUSE
WAREHOUSE_SIZE = ‘XSMALL’
AUTO_SUSPEND = 60
AUTO_RESUME = TRUE
COMMENT = ‘Warehouse for Perplexity queries’;
— Grant warehouse usage to the role
GRANT USAGE ON WAREHOUSE PERPLEXITY_WAREHOUSE TO ROLE PERPLEXITY_ROLE;
Step 3: Create the service account user
Run this as ACCOUNTADMIN. Replace the RSA_PUBLIC_KEY value with the contents of your snowflake_computer_key.pub file (without the header and footer lines).
USE ROLE ACCOUNTADMIN;
CREATE USER PERPLEXITY_USER
TYPE = SERVICE
DEFAULT_ROLE = PERPLEXITY_ROLE
DEFAULT_WAREHOUSE = PERPLEXITY_WAREHOUSE
COMMENT = ‘Service account for Perplexity’
RSA_PUBLIC_KEY = ‘MIIBIjANBgkqhki…your_public_key_here…IDAQAB’;
— Grant the dedicated role to the service account
GRANT ROLE PERPLEXITY_ROLE TO USER PERPLEXITY_USER;
Note: TYPE = SERVICE marks this as a non-human account — do not set a password. DEFAULT_ROLE = PERPLEXITY_ROLE scopes it to one dedicated role with only the privileges Perplexity needs.
Step 4: Grant access to your data
— Grant access to a specific database
GRANT USAGE ON DATABASE MY_DATABASE TO ROLE PERPLEXITY_ROLE;
— Grant access to all schemas in a database (current and future)
GRANT USAGE ON ALL SCHEMAS IN DATABASE MY_DATABASE TO ROLE PERPLEXITY_ROLE;
GRANT USAGE ON FUTURE SCHEMAS IN DATABASE MY_DATABASE TO ROLE PERPLEXITY_ROLE;
— Grant read access to all tables and views (current and future)
GRANT SELECT ON ALL TABLES IN DATABASE MY_DATABASE TO ROLE PERPLEXITY_ROLE;
GRANT SELECT ON FUTURE TABLES IN DATABASE MY_DATABASE TO ROLE PERPLEXITY_ROLE;
GRANT SELECT ON ALL VIEWS IN DATABASE MY_DATABASE TO ROLE PERPLEXITY_ROLE;
GRANT SELECT ON FUTURE VIEWS IN DATABASE MY_DATABASE TO ROLE PERPLEXITY_ROLE;
For more selective access, see the Snowflake GRANT documentation.
Step 5: Grant access to query history and access history
Perplexity uses two views in the SNOWFLAKE.ACCOUNT_USAGE schema to build a Data Map for accurate query generation:
View | Purpose |
| Query metadata, performance, and usage patterns |
| Object-level audit trail (Enterprise Edition only) |
USE ROLE ACCOUNTADMIN;
GRANT IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE TO ROLE PERPLEXITY_ROLE;
Note: ACCESS_HISTORY is only available on Snowflake Enterprise Edition or higher; Perplexity falls back to QUERY_HISTORY on Standard Edition automatically. Skipping this step reduces query accuracy. For how Perplexity uses these views, see Understanding the Data Map.
Verify access
USE ROLE ACCOUNTADMIN;
GRANT ROLE PERPLEXITY_ROLE TO USER <your_username>;
USE ROLE PERPLEXITY_ROLE;
USE WAREHOUSE PERPLEXITY_WAREHOUSE;
SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY LIMIT 5;
SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.ACCESS_HISTORY LIMIT 5;
Step 6: (Optional) Allowlist IP addresses
If your Snowflake account restricts inbound connections by IP, allowlist the IPs from this page:
USE ROLE ACCOUNTADMIN;
CREATE NETWORK POLICY PERPLEXITY_COMPUTER_POLICY
ALLOWED_IP_LIST = (…US IPs from the link above…);
ALTER USER PERPLEXITY_USER SET NETWORK_POLICY = PERPLEXITY_COMPUTER_POLICY;
Step 7: Connect Snowflake to Perplexity
For User OAuth: admin setup first
If your organization uses OAuth, an org admin configures the Snowflake (User OAuth) connector once before individual users can authenticate. In Organization Settings → Connectors → Snowflake (User OAuth), the admin sees a three-step pane:
Manage OAuth app — register Perplexity as an OAuth client against your Snowflake account. This walks you through creating a custom Snowflake
SECURITY INTEGRATIONand pasting the resulting Client ID and Client Secret back into Perplexity.Authenticate with Snowflake (User OAuth) — the admin authenticates once to verify the integration works end-to-end.
Generate a data map (optional) — optionally generate a data map for the organization (see Understanding the Data Map) and add supplementary context to improve accuracy.
In step 1, create the security integration on the Snowflake side. Run this as ACCOUNTADMIN:
USE ROLE ACCOUNTADMIN;
CREATE SECURITY INTEGRATION PERPLEXITY_OAUTH
TYPE = OAUTH
ENABLED = TRUE
OAUTH_CLIENT = CUSTOM
OAUTH_CLIENT_TYPE = ‘CONFIDENTIAL’
OAUTH_REDIRECT_URI = ‘https://ah.merge.dev/oauth/callback’
OAUTH_ISSUE_REFRESH_TOKENS = TRUE
OAUTH_REFRESH_TOKEN_VALIDITY = 7776000
OAUTH_USE_SECONDARY_ROLES = IMPLICIT
COMMENT = ‘OAuth security integration for Perplexity’;
Retrieve the Client ID and Client Secret to paste back into Perplexity:
SELECT SYSTEM$SHOW_OAUTH_CLIENT_SECRETS(‘PERPLEXITY_OAUTH’);
Once admin setup is complete, individual users can connect using the steps below.
Connect (all users)
Users only see the auth method matching the connector their admin configured.
Go to Connectors in Settings and find the Snowflake or Snowflake (User OAuth) connector.
Click Enable → Add Connector.
Authenticate using your configured method (see below).
Click Allow to complete setup.
Key-pair authentication (Snowflake connector). Enter your Snowflake account identifier, username, and private key (snowflake_computer_key.p8).
OAuth (Snowflake (User OAuth) connector). You will be redirected to Snowflake to sign in. There is no role picker — your session uses your DEFAULT_ROLE as the primary role, with your DEFAULT_SECONDARY_ROLES activated via OAUTH_USE_SECONDARY_ROLES = IMPLICIT. If your role defaults are already configured, no action is needed.
If your session is missing data you expect to see, ask your Snowflake admin to verify your DEFAULT_ROLE and DEFAULT_SECONDARY_ROLES (see User OAuth role configuration).
Using your Snowflake data
Once connected, reference your Snowflake data in Computer tasks. Mention databases, schemas, or tables and Perplexity will query them as part of multi-step workflows — all asynchronously in a secure cloud sandbox. Try queries like:
“Summarize the revenue trends from the Q4 sales table and highlight key metrics”
“Find all customer records updated in the last 30 days”
“What are the top-performing products based on the analytics schema?”
“Compare this quarter’s pipeline data against the previous quarter’s figures”
Troubleshooting
Snowflake is not enabled for your organization
If you’re in an Enterprise organization and can’t enable the connector, an admin may have disabled it. Contact your organization admin, or reach out to Perplexity support.
Connection and authentication issues
Verify Perplexity’s IP addresses are allowlisted in your Snowflake network policy.
Confirm the role has
USAGEprivileges on the required warehouses, databases, and schemas.Ask users to reconnect the connector after any policy changes.
“Invalid private key” error
Make sure you’re pasting the private key (snowflake_computer_key.p8), not the public key. The file should start with -----BEGIN PRIVATE KEY-----.
Authentication rejected by current authentication policy
Run SHOW AUTHENTICATION POLICIES as ACCOUNTADMIN and ensure PERPLEXITY_USER is covered by a policy that includes KEYPAIR. If needed:
CREATE AUTHENTICATION POLICY PERPLEXITY_AUTH_POLICY
AUTHENTICATION_METHODS = (‘KEYPAIR’)
CLIENT_TYPES = (‘DRIVERS’);
ALTER USER PERPLEXITY_USER SET AUTHENTICATION POLICY PERPLEXITY_AUTH_POLICY;
OAuth: user sees limited data after connecting
The OAuth session uses the user’s DEFAULT_ROLE as the primary role, with secondary roles activated via OAUTH_USE_SECONDARY_ROLES = IMPLICIT. If a user is missing expected access:
Confirm the security integration has
OAUTH_USE_SECONDARY_ROLES = IMPLICIT.Run
DESC USER <username>and checkDEFAULT_ROLEandDEFAULT_SECONDARY_ROLES— the session uses exactly what is configured there.If the user has no per-user role configuration and you want them to access everything granted to them, set
DEFAULT_ROLE = PUBLICandDEFAULT_SECONDARY_ROLES = (‘ALL’).Have them disconnect and reconnect the connector to issue a fresh token after changing any of these settings.
ACCESS_HISTORY view returns an error
Confirm your Snowflake account is Enterprise Edition or higher.
Insufficient privileges on ACCOUNT_USAGE views
Verify GRANT IMPORTED PRIVILEGES was run as ACCOUNTADMIN and that PERPLEXITY_ROLE is granted to the user.
Key-pair authentication fails
Re-run DESC USER PERPLEXITY_USER to confirm the public key fingerprint is populated.
If issues persist after updating these settings, contact Perplexity support for assistance.