Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.
Skip to content

Connecting to Snowflake

Getting data from Snowflake into Galdera has two parts:

  • Part 1: Connect your Snowflake account. This gives Galdera read-only access to a database in Snowflake. You enter a few details, your Snowflake administrator runs a setup script that Galdera creates, and you check that the connection works. You do this once.
  • Part 2: Import a table. You choose a table or view, tell Galdera what each column means, and import the data. You repeat this for each table you want, using the same connection.

You never enter a Snowflake password in Galdera.

Before you start

You need:

  • Your Snowflake account URL, such as ab12345.snowflakecomputing.com. Ask your Snowflake administrator if you are not sure.
  • The name of the database that holds your data.
  • An existing Snowflake user (optional). If your IT team has already created a Snowflake user for Galdera, get its name. Otherwise the script creates one called GALDERA_SVC.
  • Someone to run the setup script. This is usually your IT or data team. If you are a Snowflake administrator yourself, you can run it.
  • A table or view with a date column and the numbers you want to forecast.

Part 1: Connect your Snowflake account

Step 1: Create the setup script

  1. Open Connectors.
  2. Find Snowflake under Additional connectors and click Connect.
  3. Enter the Account URL and Database. If your team already created a Snowflake user for Galdera, enter it under Snowflake user (optional).
  4. Click Generate setup script.
  5. Click Copy script.

The setup script is specific to your connection, so it must come from Galdera. Your administrator cannot write it themselves.

Step 2: Have the script run in Snowflake

If someone else manages Snowflake, send them the script by email, chat, or ticket, and ask them to run it. The script is safe to share: it contains no passwords or secret keys. The section For your Snowflake administrator at the end of this page explains what it does, so you can send them this page too.

If you manage Snowflake yourself, open a SQL worksheet in Snowsight (Snowflake's web interface), paste the script, and run all of it. For your Snowflake administrator below lists the roles it needs.

You can close Galdera while you wait. The script is saved with the connection: to get it again, open Connectors and click Continue setup next to Snowflake.

Step 3: Check the connection

When the script has run, return to the Snowflake setup in Galdera and click Test connection. If the test fails, the message explains what to fix. See Snowflake Syncs and Troubleshooting for common errors.

When the test succeeds, your Snowflake account is connected. Galdera can now read the database, but no data has been imported yet.

Part 2: Import a table

Step 4: Choose the table

  1. Click Next to open Choose data.
  2. Choose a Schema and Table. The list shows the tables and views Galdera can read.
  3. Choose a Start date: Last 1 year, Last 2 years, Last 3 years, or Custom date. The import runs up to today. Check the sample preview to confirm it is the right data.

Step 5: Map the columns

In Review columns, tell Galdera what each column means:

  • The date column that orders the data in time.
  • At least one measure: a numeric column to forecast, such as revenue or units.
  • Any dimensions: columns to break the forecast down by, such as region or product.
  • The frequency of the data, such as daily or monthly.

Galdera suggests a role for each column. Check them, and answer any questions about the table's layout.

Step 6: Import

In Import, review your choices and click Start import.

If the date range contains no rows, Galdera shows the dates it checked. Choose an earlier start date and import again.

Your progress is saved as you go. If you leave, setup reopens at the first step you have not finished. When the import is done, the table appears under Tables on the Connectors page. To refresh its data later, open it and click Sync now.

Import another table

You do not need to connect again. On the Connectors page, click Add table, choose your Snowflake connection under Use a saved connection, and enter the database the table is in:

  • A database you already connected: go straight to Step 4.
  • A different database: Galdera shows a short script that adds read access to that database. Have it run as in Step 2, check the connection as in Step 3, then continue with Step 4.

For your Snowflake administrator

This section is for the person who runs the setup script. It explains what each part of the script does and why, so you can review it before running it.

Summary

  • Roles needed: SYSADMIN and SECURITYADMIN. The script switches between them itself.
  • Access granted: read-only (SELECT) on one database. No write, delete, or administrative privileges.
  • Objects created: one user, one role, and one X-Small warehouse, all prefixed GALDERA_.
  • Sign-in: key pair only. The user has no password and cannot sign in to the Snowflake web interface.
  • Safe to re-run: every statement either creates an object if it is missing or sets a value. Nothing is dropped or replaced.

What the script does, step by step

Your generated script contains these steps in this order. Its comments repeat the key points.

StepRuns asStatementWhat it does and why
1SYSADMINCREATE WAREHOUSE IF NOT EXISTS GALDERA_XS_WHCreates a dedicated X-Small warehouse that starts on demand and suspends after 60 seconds idle. Galdera's queries never compete with your workloads, and its cost shows separately on your bill.
2SECURITYADMINCREATE ROLE IF NOT EXISTS GALDERA_READERCreates the role that holds all of Galdera's privileges.
3SECURITYADMINGRANT ROLE GALDERA_READER TO ROLE SYSADMINPlaces the role under SYSADMIN, as Snowflake recommends for custom roles, so your administrators can see and manage it.
4SECURITYADMINCREATE USER IF NOT EXISTS GALDERA_SVC TYPE = SERVICECreates a service user. TYPE = SERVICE users cannot have a password or sign in to the web interface.
5SECURITYADMINALTER USER GALDERA_SVC SET … RSA_PUBLIC_KEY = '…'Installs Galdera's public key and sets the user's default role and warehouse. This is a separate statement so it also applies when the user already exists, for example when you re-run the script.
6SECURITYADMINGRANT ROLE GALDERA_READER TO USER GALDERA_SVC and GRANT USAGE ON WAREHOUSE GALDERA_XS_WHLets the user act as the role, and lets the role run queries on the warehouse.
7SECURITYADMINGRANT USAGE ON DATABASE …, GRANT USAGE ON ALL / FUTURE SCHEMAS …, GRANT SELECT ON ALL / FUTURE TABLES …, GRANT SELECT ON ALL / FUTURE VIEWS …Gives read access to the database. ALL covers what exists today. FUTURE covers tables and views created later, except in schemas that have their own future grants (see below).
8—DESC USER GALDERA_SVCShows the user so you can confirm the key landed: RSA_PUBLIC_KEY_FP should show a fingerprint.

SECURITYADMIN runs everything after step 1: by default it can create users and roles, and it holds the MANAGE GRANTS privilege that the grants, including FUTURE grants, require.

Schemas with their own future grants

Snowflake applies future grants at one level only. If a schema already has future grants for tables (or views), for any role, those schema-level grants take precedence, and the script's database-level future grants are ignored for that object type in that schema. Tables and views that already exist are unaffected, because the ALL grants cover them. But GALDERA_READER won't be able to read new ones created in that schema.

To check a schema:

SHOW FUTURE GRANTS IN SCHEMA <DATABASE>.<SCHEMA>;

If it lists grants for TABLE or VIEW, add schema-level future grants for Galdera for the same object type:

USE ROLE SECURITYADMIN;
GRANT SELECT ON FUTURE TABLES IN SCHEMA <DATABASE>.<SCHEMA> TO ROLE GALDERA_READER;
GRANT SELECT ON FUTURE VIEWS IN SCHEMA <DATABASE>.<SCHEMA> TO ROLE GALDERA_READER;

See Snowflake's rules for future grants on database or schema objects.

Using a user your team already created

If your organization provisions its own service users, for example SVC_GALDERA, give that name to the Galdera user connecting Snowflake so they can enter it under Snowflake user (optional). The generated script then uses your user instead of GALDERA_SVC:

  • CREATE USER IF NOT EXISTS does nothing, because the user already exists.
  • ALTER USER installs Galdera's public key and sets the default role and warehouse. It does not change the user's type, so an existing password or sign-in method stays as it is.
  • The role, warehouse, and grants are the same as for GALDERA_SVC. Galdera always connects with the GALDERA_READER role.

Before running the script, check that the user's key slot is free: DESC USER <your user> should show no RSA_PUBLIC_KEY_FP. If another tool already uses that key, the script would replace it. Contact Galdera support instead. The ownership of the user matters too: the role that runs ALTER USER must own it, or be above the role that does.

Limiting access to one schema

By default the script grants read access to every schema in the database. To limit Galdera to one schema, edit step 7 before running the script: keep GRANT USAGE ON DATABASE, and replace the other six grants with the schema-scoped versions listed in the script's comments. Then choose a table from that schema in Galdera.

Network policies

Galdera always connects from one fixed IP address, shown at the top of the script. If a network policy applies to GALDERA_SVC, add that address to the policy's allowed list, keeping its existing entries. If the script shows no address, contact Galdera support for it before testing.

How the key is handled

Galdera generates the key pair when someone clicks Generate setup script. The script contains only the public half. The private half is stored in Google Secret Manager, is used only by Galdera's connector, and is never displayed or sent to anyone. To replace the key, use key rotation: see Snowflake Syncs and Troubleshooting.

Check what Galdera can access

After running the script, you can confirm exactly what the role holds:

USE ROLE SECURITYADMIN;
SHOW GRANTS TO ROLE GALDERA_READER;
SHOW GRANTS TO USER GALDERA_SVC;

Other scripts Galdera may give you

  • Adding a second database: a short script with only step 7 for the new database. Run it as SECURITYADMIN.
  • Key rotation: a one-line ALTER USER GALDERA_SVC SET RSA_PUBLIC_KEY_2 = '…' that installs a new key alongside the current one. Run it as SECURITYADMIN.

Removing access

See Disconnect / revoke access in Snowflake Syncs and Troubleshooting.

Snowflake documentation