Understanding how Sigma uses Snowflake’s compute layer

Understanding How Sigma Uses Snowflake’s Compute Layer

Sigma Computing connects directly to Snowflake, allowing teams to explore and analyze data at scale without moving it. But to really get value out of this integration, we need to understand how Sigma uses Snowflake’s compute layer.

This blog explains what’s happening under the hood, how compute usage is triggered, and how we can optimise our workflows for speed and cost.

What is Snowflake’s Compute Layer?

• Snowflake separates storage and compute.
• Compute is handled by virtual warehouses, which run the SQL queries.
• Each virtual warehouse consumes credits when running.

Example: When we run a SELECT query from Sigma, it triggers a virtual warehouse in Snowflake to perform the operation. We pay based on:

• Size of the warehouse (e.g., Small, Medium, Large)
• Duration it runs
   

  What Triggers Compute in Sigma?

  Sigma never stores our data. Instead, it translates actions into SQL queries that Snowflake runs.

Common actions that trigger compute:

• Opening a workbook or dashboard
• Applying filters or parameters
• Creating new calculated columns
• Previewing a dataset

Example:

When a user selects "2024" from a filter, Sigma dynamically builds and sends this SQL to Snowflake.

Live Queries vs Cached Results

Sigma provides live analytics by default, but it also uses caching to reduce unnecessary compute.

How caching works:

• Sigma caches the result of recent queries.
• If the same query is run within a short period, Sigma returns cached results.
• Changing filters, fields, or datasets invalidates the cache.
  

How to Control Snowflake Spend in Sigma

Here are some ways we can reduce costs and speed up performance:

1. Set Query Timeout and Limits
   • Sigma lets us limit query run time and row count.
   • Helps avoid large accidental queries.
2. Choose Appropriate Warehouse Sizes
   • Use Small or Medium warehouses for most Sigma work.
   • Avoid auto-scaling unless needed.
3. Use Input Controls to Scope Data
   • Drop-down filters or date pickers reduce the size of result sets.
4. Use Sigma Datasets for Reuse
   • Build reusable datasets that predefine logic.
   • Reduces repeated computation.
     

Real-World Example: Monthly Sales Dashboard

We built a dashboard that shows monthly sales by region, category, and salesperson.

What happens behind the scenes:

• Sigma sends a SQL query to Snowflake with filters from the user.
• Snowflake computes the results and returns them to Sigma.
• Sigma displays the results in tables and charts.
  

Note: If the same dashboard is opened again within a few minutes without changes, Sigma uses cached results.

What Doesn’t Trigger Compute?

Sigma actions that don’t hit Snowflake include:

• Changing visualisation types (e.g., bar to line chart)
• Rearranging columns in a table
• Sorting by a field already present in the result set

This helps us avoid wasting compute on non-SQL changes.

Monitoring Usage in Snowflake

We can monitor Sigma’s compute usage directly in Snowflake:

• Use the QUERY_HISTORY view
• Filter by user, warehouse, time period

Example:

This helps us identify expensive queries and tune them.

Summary:

• Sigma relies on Snowflake for all compute operations.
• Every action in Sigma can potentially trigger a SQL query.
• Caching helps reduce repeated queries, but live analytics means compute is often active.
• We can control costs by limiting query size, using filters, and monitoring queries in Snowflake.

By understanding the connection between Sigma and Snowflake’s compute layer, we can build faster dashboards and keep our cloud bill under control.