Run Python Jobs in Snowflake¶
This topic walks you through developing, deploying, and scheduling Python scripts in Snowflake on Warehouse or Compute Pools. You can write and test your code locally using your favorite IDE or with Cortex Code, then deploy it as a Notebook Project Object — a schema-levelobject that runs your script non-interactively on a warehouse or compute pool. Once deployed, you can run your project on demand or schedule it with a task.
Code Samples¶
Please see this repository for multiple sample Python projects with setup and deployment instructions!
Tutorial¶
- Clone the samples repository and switch to the
snowpark-uv/directory. (There are other examples in the repository)
-
If you don’t already have
uvinstalled, follow the installation instructions. -
Install the development build of Snowflake CLI as a uv tool (isolated from the project
.venv):
If snow is not on your PATH, run uv tool update-shell and restart your terminal.
Connection configuration¶
- Snowpark sessions use a TOML connection file. This template expects a connection named
snowpark(passed as-c snowparkwhen deploying). Use the same name insrc/main.pyfor local runs.
- When prompted, use
snowparkas the connection name. Verify it works:
- Sync the project environment (creates
.venvand installs dependencies frompyproject.toml):
Develop and test locally¶
- Run the demo script locally to verify your environment:
- Run the test suite:
You can extend the sample scripts to read or write data specific to your team or use case. Iterate locally until your script is ready, then configure and deploy it to Snowflake.
Deployment¶
Notebook Project Objects run on Snowflake using the warehouse or compute pool you configure. The runtime and dependencies are defined in code_bundle.yml at the root of your project.
- Upload your project files to Snowflake and create a Notebook Project Object called
my_snowpark_job.
- Now that our project is deployed, we can execute
main.pyon Snowflake.
Behind the scenes this command is running the following SQL statement. If you go to the Query History page in Snowsight, you’ll be able to see this statement there.
- You can run any script in the project by changing the
--main-fileparameter:
Schedule Your Project¶
To run your project on a recurring schedule, wrap the run command in a Snowflake Task:
After creating the task, resume it to start the schedule:
Automate deployment with CI/CD¶
You can run the deploy commands in a CI/CD pipeline to automatically deploy your project when
you merge changes. The following example shows a GitHub Actions workflow that deploys on push to
the main branch:
Adapt this pattern to your CI system by running snow notebook project create --source . --overwrite after authenticating the Snowflake CLI.
Register UDFs from your project¶
If your script depends on User Defined Functions and you want to manage their lifecycle through
the project, create them during the script’s run with session.udf.register or the
@udf decorator. See src/udf_example.py in the sample project for an example.
Reference¶
The code_bundle.yml config¶
Before you deploy, configure runtime and dependency settings in the code_bundle.yml file
at the root of your project. This file sets default values so you don’t have to specify them every
time you run the project.
Here are two examples: one that runs on a warehouse and one that runs on a compute pool.
bundle¶
The top-level key for all configuration.
bundle.type¶
Required. The language runtime for the project. Supported value: python.
bundle.runs_on¶
Required. Defines the compute platform and runtime environment. Set either warehouse or
compute_pool, but not both.
For warehouse execution:
| Field | Required | Description |
|---|---|---|
warehouse | Yes | Fully qualified name of the warehouse, for example my_db.my_schema.my_wh. |
python_version | Yes | Python version to use. Supported values: 3.10, 3.11, 3.12, 3.13. |
runtime_version | No | Snowflake runtime version. |
For compute pool execution:
| Field | Required | Description |
|---|---|---|
compute_pool | Yes | Fully qualified name of the compute pool, for example my_db.my_schema.my_pool. |
query_warehouse | Yes | Fully qualified name of the warehouse to use for SQL queries. |
python_version | Yes | Python version to use. Supported values: 3.10, 3.11, 3.12. |
runtime_version | Yes | Snowflake Container Runtime version. Supported values: 2.3, 2.4, 2.5. |
accelerator | No | Hardware accelerator type. Supported values: cpu, gpu. |
bundle.properties¶
Optional type-specific settings.
| Field | Description |
|---|---|
python_packages | Path to the file that lists Python dependencies, for example requirements.txt or pyproject.toml. Dependencies are installed from the built-in snowflake.snowpark.pypi_shared_repository PyPI repository, or from the repository specified in artifact_repositories. |
bundle.artifact_repositories¶
Optional list of artifact repositories to use for installing dependencies. If not specified,
dependencies are installed from the built-in snowflake.snowpark.pypi_shared_repository repository.
For warehouse execution, specify exactly one repository. For compute pool execution, you can
specify multiple.
bundle.stage_mounts¶
Optional list of stages to mount into the runtime environment.
| Field | Description |
|---|---|
source_stage_url | The stage to mount, for example @my_stage/path. |
mount_path | The path inside the runtime to mount the stage to, for example /tmp/data. |
bundle.secrets¶
Optional list of Snowflake secret objects to make available to the runtime. Specify as fully qualified names.
bundle.external_access_integrations¶
Optional list of external access integrations that allow the project to reach external network endpoints.
bundle.env_vars¶
Optional list of environment variables to set in the runtime, specified as key-value pairs.
SQL commands¶
CREATE NOTEBOOK PROJECT¶
Create a project from a stage:
Create a project from a workspace:
For full syntax details, see CREATE NOTEBOOK PROJECT.
EXECUTE NOTEBOOK PROJECT¶
For full syntax details, see EXECUTE NOTEBOOK PROJECT.
Snowflake CLI commands¶
snow notebook project create¶
snow notebook project execute¶
snow notebook project drop¶
snow notebook project list¶
Migrate from snow_app.yml to code_bundle.yml¶
If you have an existing project that uses snow_app.yml, rename the file to code_bundle.yml
and update its contents using the mapping below.
What changed:
- The config file is now named
code_bundle.yml. - All settings are nested under a top-level
bundlekey. runtime.versionis split into two separate fields:python_version(for example,3.12) andruntime_version(the Snowflake Container Runtime version, for example2.4).runtime.compute_poolandruntime.query_warehousemove tobundle.runs_on.dependencies(a path to a file) is nowbundle.properties.python_packages.artifact_repository(a single string) is nowbundle.artifact_repositories(a list).
Before (snow_app.yml) and after (code_bundle.yml) — warehouse execution:
Before:
After:
Limitations¶
The following limitations apply:
.ipynbnotebooks can only run on compute pools, not warehouses..pyfiles can run on either.- Java and Scala are not supported.
- Event table logging is not available when running on warehouses.