100% Free Forever
AI-Powered Learning
Industry Expert Content
Certificates & Badges
Learn At Your Own Pace
Programming

Snowpark Basics

Introduces Snowpark, Snowflake's developer framework for writing DataFrame-style transformations and stored procedures in Python, Java, or Scala that execute inside Snowflake.

Advanced SnowflakeIntermediate11 min readJul 10, 2026
Analogies

What Is Snowpark?

Snowpark is Snowflake's library and runtime for writing data transformations in Python, Java, or Scala using a DataFrame API instead of raw SQL, while the actual execution still happens inside Snowflake's compute engine rather than pulling data out to a client machine. When you build a chain of Snowpark DataFrame operations (select, filter, groupBy, join), nothing runs until an action like collect() or show() is called; at that point Snowpark's query compiler translates the whole lazy DataFrame lineage into a single optimized SQL statement pushed down to the warehouse, so you get Python ergonomics with SQL-engine performance and no local data movement.

🏏

Cricket analogy: Like a captain setting an entire field placement and bowling plan before the over starts, which only actually executes ball by ball once play begins, mirroring Snowpark's lazy DataFrame building before an action triggers execution.

python
from snowflake.snowpark import Session
from snowflake.snowpark.functions import col, sum as sum_

session = Session.builder.configs(connection_parameters).create()

# Lazy DataFrame chain - nothing executes yet
orders = session.table("raw_orders")
regional_totals = (
    orders
    .filter(col("status") == "COMPLETED")
    .group_by("region")
    .agg(sum_("amount").alias("total_revenue"))
    .sort(col("total_revenue").desc())
)

# This action compiles the chain into one SQL statement and runs it
regional_totals.show()

# Register a Python UDF that runs inside Snowflake
from snowflake.snowpark.types import FloatType

@udf(return_type=FloatType(), input_types=[FloatType()])
def apply_discount(amount: float) -> float:
    return round(amount * 0.9, 2)

regional_totals.select(apply_discount(col("total_revenue"))).show()

UDFs, UDTFs, and Stored Procedures

Beyond DataFrame transformations, Snowpark lets you register Python (or Java/Scala) functions as User-Defined Functions (UDFs) that return a scalar value per row, User-Defined Table Functions (UDTFs) that can return multiple rows/columns per input, and Stored Procedures that encapsulate multi-step procedural logic (loops, conditionals, calls to other procedures) and can themselves be scheduled by a Task. Snowpark UDFs execute inside Snowflake's secure sandboxed runtime on the warehouse, with dependencies packaged via Anaconda-integrated package channels or uploaded stage files, so you can use libraries like scikit-learn or pandas directly inside a function that runs next to the data instead of shipping rows to an external Python service.

🏏

Cricket analogy: Like a specialist death-bowler brought on for exactly the last two overs to execute one precise skill, similar to a UDF being called for exactly one row-level computation within a larger query plan.

Snowpark and Python Worksheets in the Snowflake Ecosystem

Snowpark integrates with Snowflake's broader Python ecosystem: Snowpark ML provides distributed, scalable versions of common scikit-learn-style preprocessing and modeling APIs that execute on Snowflake warehouses, and Python-based Streamlit apps can be deployed to run natively inside Snowflake (Streamlit in Snowflake) and query data through Snowpark sessions without any data leaving the platform's governance boundary. This matters for regulated industries where moving data to an external notebook or ML platform creates compliance and data-residency risk; Snowpark keeps the computation where the governed data already lives.

🏏

Cricket analogy: Like a franchise that keeps its entire analytics team embedded inside the stadium's own data room during a match, rather than shipping sensitive player biometric data out to a third-party consultancy.

Snowpark DataFrames are lazily evaluated — building a chain of .filter(), .select(), and .groupBy() calls costs nothing until you call an action like .collect(), .show(), or .to_pandas(), at which point the entire chain compiles into one pushed-down SQL query.

Calling .toPandas() or .collect() on a very large DataFrame pulls the full result set into local Python memory on the client (or the stored procedure's sandbox), which can cause out-of-memory errors. Prefer aggregating or filtering down within the lazy DataFrame chain before materializing results locally.

  • Snowpark provides a DataFrame API in Python, Java, and Scala that compiles lazily into pushed-down SQL executed inside Snowflake.
  • No actual computation happens until an action like .collect(), .show(), or .to_pandas() is called on the DataFrame chain.
  • Snowpark UDFs, UDTFs, and Stored Procedures let you run custom Python/Java/Scala logic inside Snowflake's secure sandboxed runtime.
  • Third-party packages (e.g., scikit-learn, pandas) can be used inside UDFs via Anaconda-integrated channels without leaving Snowflake.
  • Snowpark ML and Streamlit in Snowflake extend the same in-platform execution model to model training and interactive apps.
  • Keeping computation inside Snowflake avoids moving governed data to external notebooks or ML platforms, reducing compliance risk.
  • Materializing very large DataFrames locally with .collect() or .toPandas() risks out-of-memory errors; filter/aggregate first.

Practice what you learned

Was this page helpful?

Topics covered

#Programming#SnowflakeStudyNotes#SnowparkBasics#Snowpark#UDFs#UDTFs#Stored#StudyNotes#SkillVeris#ExamPrep