Connect Data in Snowflake
Connect your Snowflake notebook to tables and views in a Snowflake schema. Complete Snowflake Notebook Setup first, including local working storage. If setup already created your connector, reuse it and run the access check below.
Choose a source
Running Python on Linux instead? Use the Linux Snowflake connection.
Snowflake tables and views
The notebook role needs access to the query warehouse, database, schema, and source tables or views. Use the query warehouse that can read your data; this is separate from the compute pool running the notebook. Replace COMPUTE_WH, ANALYTICS, and PUBLIC with your warehouse, database, and schema:
from_spcs_env() reads the runtime account, host, and mounted OAuth token. Do not copy the token into the notebook. An active Snowpark session alone does not provide these credentials. If runtime credentials are missing, check that you are using the container notebook environment from setup.
Check source access
List the available tables, then inspect one of them. Replace ORDERS with a name from the listing, preserving its capitalization:
Expect the selected table’s column names. This verifies discovery and schema access; the graph snapshot reads the data later. If the listing is empty or the expected table is missing, check the configured database and schema and the role’s source grants. If reading columns fails, confirm the exact table name and the role’s warehouse and source access.
Continue to Tables to define keys, time columns, and features, or follow the complete Snowflake notebook example.
Advanced configuration
Select another source schema
Create another connector with the same runtime helper and the target warehouse, database, and schema. The notebook role needs access to that location too. For example, replace REFERENCE_DATA with the schema you want to read:
Use the Linux guide’s password and key pair procedure only when deliberately connecting with a separate identity.
Prepare prediction outputs
Use a dedicated output schema for saved prediction tables. Have the schema owner create it first and grant the execution role USAGE on the database, schema, and query warehouse, plus CREATE TABLE and CREATE FILE FORMAT on the output schema. Kumo uploads local prediction files to the authenticated user’s stage and creates a temporary file format to infer the output table schema. This workflow does not require creating a named stage. See Snowflake’s file format privileges.
Writing to an existing table requires INSERT, plus DELETE for overwrite. Reading the saved output also requires SELECT on that table. Source-read access alone is insufficient. In a scheduled job, grant these permissions to the job’s execution role.
Continue to choose the prediction output location to configure the output connector, then score and verify the saved table.
Retain predictions and models
Use Snowflake tables for prediction outputs and Snowflake Model Registry for model retention. Source read grants do not authorize output writes. Notebook scratch paths are temporary working files, not Snowflake tables or stages.
Reuse the connector after a restart
After a kernel restart, rerun the import, working storage configuration, and connector cells from setup. Connectors are Python objects rather than entries in a persistent Kumo connector registry. If a source schema changes, obtain a new reference with connector.table("ORDERS") before inspecting its columns again.