Snowflake to Sigma
Sigma queries Snowflake live and generates SQL that runs in your warehouse. The workbooks are only as good as the tables they read, so we model those first.
The short answer
What Sigma reads from Snowflake
- Modeled reporting tables
- Dated tables with a set grain, keys and refresh timing, so business users never need to open raw schemas.
- Shared metric definitions
- Each calculation written once and reused, so two workbooks do not calculate the same number in different ways.
- Input table schemas
- Input tables write the data users enter to designated schemas in Snowflake, for comments, approvals and plan values.
- Snowflake functions and procedures
- Passthrough functions call Snowflake functions Sigma lacks, and actions can run a stored procedure.
How we set it up
- 1
Name the decision
We define who will use the workbook, what they need to decide, and what a correct answer looks like.
- 2
Set grain and ownership in Snowflake
We pin down keys, calculations, refresh timing and ownership in Snowflake tables before those choices get buried in a workbook.
- 3
Build and test the workbook
We test filters, totals, drill paths, permissions and layouts in the published workbook, comparing results at total, month, region and record level.
- 4
Schedule delivery
Scheduled exports and email bursts send each reader their version. We check what else runs in the warehouse at the send time.
What breaks, and how we handle it
- Data that only lives in an extract
- Sigma needs the data in a connected platform. Data that exists only in a Tableau extract or Power BI import has to land in Snowflake first, as its own piece of work.
- Joins that multiply totals
- If every value is exactly tripled after a join, the grain is wrong. We check grain before tuning any formula.
- Partial months on live data
- Any chart on live data gets a short last bar that looks like a collapse. We filter the chart to completed months instead of filtering the source table.
- Bursts multiply warehouse queries
- Sigma queries the document once per split value, so a burst with 40 regions runs 40 queries. We simplify the document, use materializations, or send outside peak hours.
- A matching total can hide different rows
- We freeze the population and compare the qualifying record IDs before trusting any aggregate.
What we build on top of the Snowflake data
- Dated reporting tables with history for any past day
- Shared metric definitions reused across workbooks
- Input table schemas for writeback and approvals
- Recipient mapping table for personalized PDF bursts
- Validation record comparing source results with Sigma
Common questions
Does Sigma copy my Snowflake data?
Sigma connects to Snowflake and runs live queries, generating SQL that runs in your warehouse, rather than relying on extracts. How fast it feels depends on your warehouse and how the data is modeled.
Can Sigma users write data back to Snowflake?
Yes. Input tables write the data users enter to designated schemas in your warehouse, and actions can insert or update rows, call an API, run a stored procedure or send an export.
Can I use Snowflake functions that Sigma does not have?
Yes, through passthrough functions. The Call functions run a row-level Snowflake function and the Agg functions run an aggregate one. Pick the one that matches the data type returned.
Why does the last month on my Sigma chart look so low?
Live data runs only a few days into the current month. Filter the chart to a relative date range and turn off the current month, or end a date range control at the last completed month.
Will a Sigma email burst load my warehouse?
Each split value runs its own warehouse query, and Sigma processes bursts in batches. If bursts time out, simplify the document, use materializations, or schedule outside peak warehouse hours.
Want Snowflake data you can trust?
Bring the Snowflake reports that don't match. We'll trace them to the source and show you where to start.