About the Snowflake Connector
The Snowflake Connector enables you to query data stored in your Snowflake data warehouse directly from Perplexity. It integrates Snowflake with Perplexity's productivity features, allowing you to instantly search and combine relevant information across your Snowflake databases, email, calendar, other connected apps, and the web — without manual queries or context switching.
The Snowflake Connector is available for Perplexity Pro, Perplexity Max, Enterprise Pro, and Enterprise Max users.
What does the Snowflake Connector do?
Once enabled, the Snowflake Connector allows you to search across your authorized Snowflake databases, schemas, and tables to provide answers based on that data. The connector works by securely connecting to your Snowflake account, enabling comprehensive searches that combine information from your warehouse with other sources.
You can use the connector to quickly find information across tables, views, and schemas without manually writing SQL queries or switching to the Snowflake console. When your Snowflake data is updated, the connector reflects those changes automatically during subsequent queries.
Supported Data Objects
The Snowflake Connector supports:
Tables
Views and materialized views
Schemas
Databases
Structured data (CSV, JSON, Parquet-backed tables)
At the moment, unstructured data (images, audio, and video stored in Snowflake stages) is not supported.
Authentication Methods
Snowflake authentication has two independent dimensions: who the queries run as (identity), and how that identity proves itself (credential). Most combinations are valid in Snowflake — see the Snowflake Partner Authentication docs.
Identity (Snowflake user type):
TYPE = PERSON— an individual Snowflake user account, one per Perplexity userTYPE = SERVICE— a single shared service account (e.g.,PERPLEXITY_USER) that all Perplexity users query through
Credential (how that user authenticates):
OAuth (browser-based flow)
Key-pair (RSA private key)
Programmatic Access Token (PAT)
Identity × Credential Matrix
| OAuth | Key-pair | PAT |
| ✅ Recommended | ✅ Supported in Snowflake | ✅ Supported in Snowflake |
| ❌ Not supported (OAuth requires interactive login) | ✅ Recommended for service account | ✅ Supported (single role only) |
⚠️ What Perplexity's connector UI exposes today:
Perplexity ships two separate connectors in the directory:
"Snowflake (User OAuth)" — for
PERSON+ OAuth (per-user identity, recommended)
"Snowflake" — for
SERVICE+ key-pair, orSERVICE+ PAT (shared identity, fallback)
Per-user key-pair or PAT (PERSON + key-pair / PERSON + PAT) is technically supported by Snowflake but not currently exposed by Perplexity's connector UI. If you have a customer asking for it (e.g., user-level key-pair without OAuth), reach out to the connectors team — it is not blocked by Snowflake.
Recommended Path: User OAuth
We recommend User OAuth (PERSON + OAuth). Each Perplexity user authenticates with their own Snowflake credentials, queries run under that user's native Snowflake permissions, and you get a clear per-user audit trail in Snowflake — no shared service account, no need to recreate RBAC logic in Perplexity. This also aligns with Snowflake's own direction: per Snowflake, "Key-pair and PAT are fallback options for service accounts that can't use OAuth", and Snowflake's managed MCP server only supports OAuth 2.0 today.
Note: With OAuth, the access token is cryptographically bound to a specific Snowflake role at authentication time — specifically, the user's DEFAULT_ROLE. To ensure users still have access to all roles granted to them within a session, configure secondary roles correctly (see User OAuth Role Configuration below).
Fallback Path: Service Account
Service account (SERVICE + key-pair, or SERVICE + PAT) is appropriate when:
End users do not have individual Snowflake accounts (for example, business users querying through Perplexity but without direct Snowflake access)
You explicitly want all Perplexity queries to run under a single shared identity for simplicity or auditing reasons
You are setting up an internal/test environment where per-user identity is not required
When using service account, we recommend key-pair over PAT — PATs have shorter expiration windows and bind to a single role at creation time (see Service Account Role Configuration below).
Role Configuration
User OAuth Role Configuration (Recommended)
OAuth authentication in Snowflake binds the access token to a single primary role — the user's DEFAULT_ROLE — and role switching within an active session is not supported. Perplexity does not present a role-picker. Whatever the user already has configured in Snowflake for DEFAULT_ROLE and DEFAULT_SECONDARY_ROLES is what the OAuth session uses.
Recommended 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 user's primary role active — any secondary roles they've been granted are not activated. Setting it to IMPLICIT tells Snowflake to also activate each user's DEFAULT_SECONDARY_ROLES automatically when the OAuth session opens. The integration will function either way, but without IMPLICIT users will only see data accessible via their DEFAULT_ROLE, regardless of what other roles they've been granted — which is rarely what you want and is what makes the rest of this guidance work.
Two cases
Case A — Users already have role defaults configured. If your users' DEFAULT_ROLE and DEFAULT_SECONDARY_ROLES are already set up the way you want them (per-user RBAC, custom default roles, specific secondary role lists, etc.), do nothing else. The IMPLICIT security integration setting is sufficient — each user's existing defaults are what their Perplexity session will use.
Case B — Users do not yet have role defaults. If you have not configured per-user role defaults, the recommended pattern is to set every user's DEFAULT_ROLE to PUBLIC and set DEFAULT_SECONDARY_ROLES to ALL. Combined with OAUTH_USE_SECONDARY_ROLES = IMPLICIT at the integration, this gives each session the union of all roles granted to that user:
ALTER USER <username> SET
DEFAULT_ROLE = PUBLIC,
DEFAULT_SECONDARY_ROLES = ('ALL');
Note: As of Snowflake's August 2024 behavior change, DEFAULT_SECONDARY_ROLES = ('ALL') is the new account-level default for newly-created users. Many orgs already have this set without any explicit action. Run DESC USER <username> to check before changing anything.
Service Account Role Configuration
Unlike OAuth, a service account is a single dedicated user that runs under one specific role created for the connector — typically PERPLEXITY_ROLE. The DEFAULT_ROLE = PUBLIC + DEFAULT_SECONDARY_ROLES = ('ALL') pattern used for OAuth does not apply here. Instead, set the service user's DEFAULT_ROLE to the dedicated PERPLEXITY_ROLE, and grant that role only the permissions Perplexity needs.
Apply this when creating the service account user (using key-pair authentication, which we recommend over PAT):
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';
This follows Snowflake's service account best practices: the service user is scoped to a single, narrowly-permissioned role rather than inheriting the union of every role granted to it.
Service Account with PAT
If you use a Programmatic Access Token instead of key-pair, Snowflake requires ROLE_RESTRICTION to be set at token creation time. The token is hard-bound to the single role specified in ROLE_RESTRICTION and cannot be changed for the life of the token.
Use the same dedicated PERPLEXITY_ROLE here:
ALTER USER PERPLEXITY_USER ADD PROGRAMMATIC ACCESS TOKEN PERPLEXITY_PAT
ROLE_RESTRICTION = 'PERPLEXITY_ROLE'
DAYS_TO_EXPIRY = 90;
For this reason — combined with shorter expiration windows — we recommend key-pair over PAT for service account setups.
(Optional) Restricting Which Roles Can Be Used via OAuth
If you want to limit which Snowflake roles users can authenticate into via the Perplexity OAuth integration, you can scope this at the security integration level using either:
PRE_AUTHORIZED_ROLES_LIST— explicit allowlist of roles that can be used through this OAuth integrationBLOCKED_ROLES_LIST— denylist of roles that cannot be used through this OAuth integration
For example:
ALTER SECURITY INTEGRATION PERPLEXITY_OAUTH SET PRE_AUTHORIZED_ROLES_LIST = ('ANALYST_ROLE', 'READ_ONLY_ROLE');Use this if you want to keep sensitive roles (e.g., ACCOUNTADMIN) out of the OAuth flow entirely.
Controlling What Perplexity Can Do in Snowflake
The Snowflake Connector executes SQL through a tool surface (sourced from the Merge Snowflake connector) that includes a general execute_sql tool. Because execute_sql accepts arbitrary SQL — including DDL and DML — the only reliable way to enforce read-only or otherwise restrict what Perplexity can do is at the Snowflake RBAC layer, not in the Perplexity UI.
Recommended pattern: enforce read-only at the Snowflake role level.
Provision a dedicated read-only role (e.g., PERPLEXITY_READ_ONLY) granting only USAGE and SELECT on the databases, schemas, and tables you want Perplexity to query — and explicitly not granting INSERT, UPDATE, DELETE, CREATE, DROP, OWNERSHIP, or warehouse MODIFY. Then ensure users authenticate into that role:
Set it as the user's
DEFAULT_ROLE, orScope the OAuth integration with
PRE_AUTHORIZED_ROLES_LIST = ('PERPLEXITY_READ_ONLY', …)and/or exclude write-capable roles viaBLOCKED_ROLES_LIST(see (Optional) Restricting Which Roles Can Be Used via OAuth above).
With RBAC configured this way, Snowflake will reject any write Perplexity attempts, regardless of which tool is called.
Note: Perplexity surfaces a Tool permissions panel in the Snowflake connector settings that lists the available tools. Today, this panel does not provide reliable read/write/edit enforcement — governing access at the Snowflake role level (above) is the correct way to control what Perplexity can do.
Privacy and Data Security
When connected to Perplexity, the Snowflake Connector can perform the following actions on your behalf:
Execute SQL queries on Snowflake data
Query Cortex Search and 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 your Snowflake account 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 Perplexity to Snowflake is done at a personal level — no one else in your organization can query your Snowflake data. However, if you sync data to a shared Space, anyone with access to that Space will be able to search it.
Organization admins can enable or disable the Snowflake 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 in Snowflake above).
How to activate it
Note: We recommend User OAuth for most organizations — it provides per-user identity and aligns with Snowflake's own direction. Service account (key-pair) is offered as a fallback when individual Snowflake accounts are not available. If you are using User OAuth, see Step 7: Connect Snowflake to Perplexity for the admin-only OAuth setup. The SQL setup steps 1–6 below apply to service account / key-pair setups only.
Prerequisites
ACCOUNTADMINrole (or a role withCREATE USERandGRANTprivileges)OpenSSL installed on your local machine (pre-installed on macOS)
Step 1: Generate a Key Pair
From your terminal, generate an RSA private key:
openssl genrsa 2048 | openssl pkcs8 -topk8 -inform PEM -out snowflake_computer_key.p8 -nocrypt
Next, generate the corresponding 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 = 'XLARGE'
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 the following in a Snowflake worksheet using the ACCOUNTADMIN role. Replace the RSA_PUBLIC_KEY value with the contents of your snowflake_computer_key.pub file without the header and footer.
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 designates this as a non-human service account. Do not set a password. DEFAULT_ROLE = PERPLEXITY_ROLE scopes the service account to one dedicated role with only the permissions 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 relies on two views in the SNOWFLAKE.ACCOUNT_USAGE schema to build a Data Map for accurate query generation:
View | Purpose |
QUERY_HISTORY | Query metadata, performance, and usage patterns |
ACCESS_HISTORY | 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 will fall back to QUERY_HISTORY on Standard Edition automatically. Skipping this step will result in decreased query accuracy. For more detail on how Perplexity uses these views to build a Data Map for your data, 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 has a network policy that restricts inbound connections by IP address, 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 OAuth: Admin Setup First (Snowflake (User OAuth) connector)
If your organization is using OAuth (individual user) authentication, an org admin needs to configure the Snowflake (User OAuth) connector once for the organization before individual users can authenticate.
In Organization Settings → Connectors → Snowflake (User OAuth), the admin will see a three-step setup pane:
Step 1: Manage OAuth app — Click Manage OAuth app to 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.Step 2: Authenticate with Snowflake (User OAuth) — The admin authenticates once to verify the integration works end-to-end.
Step 3: Generate a data map (Optional) — Optionally generate a data map for the organization (see Understanding the Data Map) and add Supplementary context to improve query accuracy.
When you click Manage OAuth app in Step 1, you'll need to create the security integration on the Snowflake side. Run the following 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 authenticate using the steps below.
User Connection Steps
Users will only see the auth method matching the connector their admin configured — Key-pair or PAT under the Snowflake connector, OAuth under the Snowflake (User OAuth) connector.
Go to Connectors in Settings and locate the Snowflake or Snowflake (User OAuth) connector.
Click Enable → Add Connector.
Authenticate using whichever method your connector is configured for:
Key-pair authentication (Snowflake connector)
Enter your Snowflake account identifier, username, and private key (snowflake_computer_key.p8).
Programmatic Access Token (PAT) (Snowflake connector)
Enter your Snowflake account identifier and a PAT from Governance & Security in Snowflake.
OAuth (individual user) (Snowflake (User OAuth) connector)
You'll be redirected to Snowflake to authenticate. Perplexity does not present a role-picker — your OAuth session uses your Snowflake DEFAULT_ROLE as the primary role, with your DEFAULT_SECONDARY_ROLES automatically activated via OAUTH_USE_SECONDARY_ROLES = IMPLICIT. If your role defaults are already configured by your admin, no action is needed.
If you find your session is missing access to data you expect to see, ask your Snowflake admin to verify your DEFAULT_ROLE and DEFAULT_SECONDARY_ROLES (see User OAuth Role Configuration above).
Click Allow to complete setup.
Using Connected Data
Once connected, you can 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.
Trying it out
Once connected, try running queries like these:
"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 a member of an Enterprise organization and can't enable the Snowflake Connector, an admin may have disabled it. Contact your organization admin to confirm, 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 required warehouses, databases, and schemasAsk users to reconnect the Snowflake Connector after any policy changes
"Invalid private key" error
Ensure 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. Ensure PERPLEXITY_USER is covered by a policy that includes KEYPAIR in its allowed methods. 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 Snowflake DEFAULT_ROLE as the primary role, with secondary roles activated via OAUTH_USE_SECONDARY_ROLES = IMPLICIT. If a user is missing access to data they expect to see:
Confirm the security integration has
OAUTH_USE_SECONDARY_ROLES = IMPLICIT.Run
DESC USER <username>and checkDEFAULT_ROLEandDEFAULT_SECONDARY_ROLES. The session will use 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 Snowflake Connector to issue a fresh token after any of these settings change.
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 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.