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.
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.
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.
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).
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.
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 \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 \ to check before changing anything.
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.
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.
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, or
Scope the OAuth integration with PRE\_AUTHORIZED\_ROLES\_LIST and/or exclude write-capable roles with BLOCKED\_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.
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.
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).
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.
ACCOUNTADMIN role (or a role with CREATE USER and GRANT privileges)
OpenSSL installed locally (pre-installed on macOS) — service-account setups only
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
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;
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.
-- 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.
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.