Skip to content

Snowflake

Connect Querri to your Snowflake account, choose the tables you want, and ask questions about them in plain language.

The Snowflake connector reads the databases and schemas your Snowflake role can see. For each table you choose, you decide how Querri uses it:

  • Synced (the default): Querri copies the table into its own storage on the schedule you set.
  • Live: the table stays in Snowflake, and each question runs as a query in your warehouse. See Live Tables.

The connector signs in with a key pair or a programmatic access token. Snowflake is reached over HTTPS, so there’s no port to set and no VPN option.

You’ll need:

  • Your account identifier. In Snowsight, open the account menu, then Account → View account details. It looks like myorg-myaccount, or xy12345.us-east-1 for older accounts. A full *.snowflakecomputing.com address also works.
  • Someone who can run SQL as ACCOUNTADMIN, once, to create Querri’s user and role.
  • A warehouse for the queries to run on. Querri can create a small one for you.

The easiest way is to let Querri write the setup script for you.

  1. In the connector form, choose Key pair (recommended) under Authentication.
  2. Fill in Username, Role and Warehouse if you want your own names. Leave them blank and the script uses QUERRI_SVC, QUERRI_RO and QUERRI_WH. If you name a warehouse you already have, the script grants use of it instead of creating a new one.
  3. Under Guided setup, enter the Database to grant read access to, such as ANALYTICS. You can grant more databases later.
  4. Click Generate key pair & SQL. Querri creates the key pair and keeps the private key encrypted. It’s never shown.
  5. Copy the script and run it in a Snowsight worksheet as ACCOUNTADMIN.

The script creates a service user that can’t hold a password, a read-only role, and (unless you named one) an extra-small warehouse that suspends after 60 seconds idle. Nothing in it creates or changes your data.

If your security policy requires you to create and hold the key yourself, generate a key pair, register the public key on the user with ALTER USER … SET RSA_PUBLIC_KEY, and paste the private key under Or paste an existing private key. These are the read grants Querri needs, the same ones the guided script uses:

GRANT USAGE ON WAREHOUSE QUERRI_WH TO ROLE QUERRI_RO;
GRANT USAGE ON DATABASE ANALYTICS TO ROLE QUERRI_RO;
GRANT USAGE ON ALL SCHEMAS IN DATABASE ANALYTICS TO ROLE QUERRI_RO;
GRANT USAGE ON FUTURE SCHEMAS IN DATABASE ANALYTICS TO ROLE QUERRI_RO;
GRANT SELECT ON ALL TABLES IN DATABASE ANALYTICS TO ROLE QUERRI_RO;
GRANT SELECT ON FUTURE TABLES IN DATABASE ANALYTICS TO ROLE QUERRI_RO;
GRANT SELECT ON ALL VIEWS IN DATABASE ANALYTICS TO ROLE QUERRI_RO;
GRANT SELECT ON FUTURE VIEWS IN DATABASE ANALYTICS TO ROLE QUERRI_RO;

For a shared database, such as one from a data share or SNOWFLAKE_SAMPLE_DATA, use a single grant instead:

GRANT IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE_SAMPLE_DATA TO ROLE QUERRI_RO;

Keep the role read-only. Querri only reads, and that holds for Live tables too.

  1. Open the connector. Click Connect in the app rail and pick Snowflake, or click Connect on it in Settings → Connectors (admins).

  2. Enter connection settings under Connection Settings:

    FieldNotes
    Connector NameDefaults to Snowflake
    Account Identifier *See Before you start
    RoleOptional. Leave blank to use the user’s default role, which the setup script sets
    WarehouseOptional for the script, but every query needs one. Name the warehouse Querri should use
    UsernameThe Snowflake user Querri signs in as
    Authentication *Key pair (recommended) or Programmatic access token
    DatabaseOptional. Leave blank to discover databases from the account
  3. Test the connection. Click Test connection and discover access. This saves the connector, then connects and lists the databases and schemas the role can read. A connection without a usable warehouse fails the test on purpose, because every query would fail later.

  4. Choose a database and schema. Under Select Data, pick a database. For the schema, All schemas lists every table in the database, which is usually what you want: warehouse data tends to live in named schemas rather than PUBLIC. Or pick one schema.

  5. Choose tables. Under Table Selection, All Tables is on by default. Turn it off to pick tables yourself. Each table shows its row count, so you can spot the big ones.

  6. Keep each table synced, or make it Live. Each selected table has a Live switch. Leave it off to copy the table into Querri, or turn it on to keep the table in Snowflake and query it there. See Live Tables.

  7. Add custom queries, if you need them. Under Custom SQL Queries, you can load the result of your own query as a source. Custom queries run read-only under the connector’s role, with a 10-minute limit. If you can create a view in Snowflake instead, prefer that: views appear in the table picker and stay under your own access controls.

  8. Check advanced settings. Under Advanced Settings, Limit rows per table caps how many rows each synced table loads. Statement timeout caps how long one query may run, so a runaway pull can’t hold your warehouse for long.

  9. Load your data. Click Save and Load Data. A progress card shows each synced table loading. Live tables aren’t copied, so Querri keeps only their columns and an estimated row count.

The connector’s owner can keep synced tables up to date on the Schedule tab:

  • Full Refresh reloads every synced table.
  • Incremental fetches only new or changed rows, using a cursor column such as updated_at. Tables without that column are skipped by the incremental schedule.

The Live tab sits next to them. It’s where you choose Live tables after setup, and set a schedule that refreshes their columns and row estimates without copying rows.

Scheduled syncs use credits when they run. See Sync Scheduling.

The connection has no warehouse to run queries on. Enter one under Warehouse, and check the role has USAGE on it.

”User does not exist or not authorized” right after running the script

Section titled “”User does not exist or not authorized” right after running the script”

The script only partly ran. Run it again with Run All (Cmd or Ctrl + Shift + Enter).

Shared databases don’t accept the usual USAGE and SELECT grants. Use GRANT IMPORTED PRIVILEGES ON DATABASE … TO ROLE … instead.

  • Check the Role. A blank role means the user’s default role, and a user without one falls back to PUBLIC, which usually can’t see anything.
  • Check the role has USAGE on the database and schemas, and SELECT on the tables.
  • Set the schema to All schemas. A single schema such as PUBLIC is often empty in a warehouse.

The connection stopped working after a few weeks

Section titled “The connection stopped working after a few weeks”

If you used a programmatic access token, it has probably expired. Tokens last 15 days by default. Switch to a key pair for unattended syncs.

Check the Account Identifier: use the account identifier, not the account name, organization name or a URL path. If your account has a network policy, allow Querri’s outbound address in it.

A warehouse that has auto-suspended takes a few seconds to resume. Later queries are faster while it stays running.

Querri tags its queries, so you can find them in Snowflake’s query history by their query tag.