Why Snowpark brings code to the data in Snowflake - Visual Breakdown

Process Flow - Why Snowpark brings code to the data

User writes code locally

↓

Code sent to Snowflake platform

↓

Code runs inside Snowflake near data

↓

Results sent back to user

↓

User gets output quickly and securely

This flow shows how Snowpark moves your code to where the data lives inside Snowflake, instead of moving data to your code.

Execution Sample

Snowflake

session.sql("SELECT * FROM sales WHERE amount > 100").collect()

This code runs inside Snowflake, filtering data close to where it is stored.

Process Table

Step	Action	Location	Data Movement	Result
1	User writes Snowpark code	User machine	No data moved	Code ready to send
2	Code sent to Snowflake	Network	Code moves, data stays	Code received by Snowflake
3	Code executes near data	Snowflake server	No data movement needed	Filtered data prepared
4	Results sent back	Network	Only filtered results move	User receives output
5	User processes results	User machine	No extra data movement	Final output ready

💡 Execution stops after results are returned to user, minimizing data transfer.

Status Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	Final
Code	Local script	Sent to Snowflake	Executing	Executed	Complete
Data	In Snowflake	In Snowflake	Filtered in Snowflake	Filtered results sent	User received results

Key Moments - 3 Insights

Why doesn't Snowpark move all data to the user's machine?

Because moving large data is slow and costly. Snowpark runs code inside Snowflake where data lives, so only small results move back, as shown in execution_table rows 2 and 3.

How does running code near data improve speed?

It avoids delays from transferring big data over the network. execution_table row 3 shows code running inside Snowflake, filtering data before sending results.

What moves over the network when using Snowpark?

Only the code and the filtered results move, not the entire dataset. This is clear in execution_table rows 2 and 4.

Visual Quiz - 3 Questions

Look at the execution_table, at which step does the code start running near the data?

A Step 1

B Step 2

C Step 3

D Step 4

💡 Hint

Check the 'Location' and 'Action' columns in execution_table row 3.

According to variable_tracker, what happens to the data after step 3?

A Data moves to user machine

B Data is filtered inside Snowflake

C Data is deleted

D Data is copied to another server

💡 Hint

Look at the 'Data' row under 'After Step 3' in variable_tracker.

If Snowpark moved all data to the user machine, which execution_table step would change?

A Step 4

B Step 3

C Step 2

D Step 5

💡 Hint

Consider where data moves over the network in execution_table, especially step 4.

Concept Snapshot

Snowpark sends your code to Snowflake where data lives.
Code runs inside Snowflake, close to data.
Only filtered results move back to you.
This reduces data transfer and speeds up processing.
It keeps data secure and efficient.

Full Transcript

Snowpark works by sending your code to run inside Snowflake, where the data is stored. This means the data does not move to your computer. Instead, your code runs near the data, filtering or processing it there. Then, only the small results are sent back to you. This approach saves time and network resources, making data processing faster and safer. The execution flow starts with you writing code, sending it to Snowflake, running it near the data, and finally receiving the results.