Reducing Latency in Sigma Dashboards (Part 2)

Summary

As your team scales its BI usage, Sigma dashboards can slow down—especially when working with complex lineage, layered queries, and massive datasets. Fortunately, there are a few more ways to speed things up without sacrificing functionality. In this follow-up, we’ll walk you through two additional strategies: materializing datasets and organizing dashboard structure.

The Latency Challenge Continued

In a previous article, we discussed how trimming columns and applying base-level date filters could drastically reduce query load in Sigma dashboards. But in some cases, that's not enough. Especially when your dashboard pulls directly from Snowflake, Databricks, or other live sources with gigabytes of data and complex joins, Sigma ends up generating nested SQL logic and waiting for live fetches every time the dashboard is opened.

To tackle this, we explored two more solutions that helped our dashboards become even faster and more stable in production settings.

Solution III. Use Dataset Materialization in Sigma

Materialization is a concept in data engineering where you create a "pre-built" version of your data—kind of like saving a draft of a spreadsheet instead of recalculating formulas every time you open it. In Sigma, this means the table is refreshed on a schedule (daily, hourly, etc.) rather than querying Snowflake or Databricks live every single time.

• Step 1 - Convert to a Materialized Dataset: Sigma allows you to materialize any dataset by going to the dataset’s options and setting a refresh cadence. You can choose to update hourly, daily, or weekly depending on how often the data changes.


• Step 2 - Reduce Live Query Load: Once materialized, Sigma serves the data from its own storage instead of your live data warehouse. This takes massive pressure off Snowflake or Databricks, and drastically improves dashboard load time and reliability.


• Step 3 - Choose Smart Cadence: If your data updates once a day, don’t refresh it every hour. Set the cadence thoughtfully to balance performance and data freshness.

Result: Switching just one core table to a materialized dataset cut our dashboard load time from 12 seconds to under 4 seconds, and dropped our Snowflake compute cost by over 30% in some cases.

Solution IV. Clean Up and Organize Dashboard Lineage

As dashboards evolve, people often keep building visualizations on top of each other. This results in deep and tangled lineage trees, where Sigma builds SQL with multiple layers of CTEs (common table expressions). That’s a recipe for sluggish performance.

• Step 1 - Separate Base Tables and Visuals: Move all heavy data tables to a dedicated tab in your workbook. This keeps them clean and prevents accidental use of full tables in child elements.


• Step 2 - Build Summary Tables: Create intermediate summary tables with only the fields and aggregations you actually need for visualizations. These summary tables can then feed lightweight KPI cards, pivot tables, and charts that don’t require pulling full detail from the base.


• Step 3 - Delete Extra Columns: After summarizing, go back and remove any unused columns in your visuals. This makes each layer of your dashboard as lean as possible.

Result: In one dashboard, this reduced query complexity from 5+ CTE layers to just 2. That alone brought load time down by over 40%.

Diagnosing Issues with “Query History”

If you’re unsure what’s causing slow load time, use Sigma’s “Query History” feature from the dashboard menu. This shows exactly which visual is running which SQL query and how long it takes. In many cases, you’ll spot:

• Too many elements loading at once (e.g., 10+ cards loading simultaneously)
• Deep lineage with layered queries that are hard for Snowflake to optimize

Query History helps pinpoint the bottlenecks, so you can focus your optimization efforts where they matter most.

Bonus: Optimizing Snowflake Settings

If you’ve optimized Sigma and still see lag, you can check your Snowflake warehouse configuration:

• Warehouse Size: Larger warehouses (Small, Medium, etc.) process queries faster but cost more.
• Max Concurrency Level: If too many Sigma users are querying at once, Snowflake queues some queries. You can raise the max_concurrency_level or spin up multiple virtual warehouses to avoid this.

Note: These changes improve performance, but come with increased cost, so evaluate based on usage patterns.

Conclusion

Speed matters. If your Sigma dashboard isn’t fast, it won’t get used—no matter how pretty it looks. By materializing your datasets and restructuring your dashboard lineage, you can dramatically reduce query times and costs.

Combined with the first two techniques (column cleanup and base-level date filters), these four strategies form a powerful toolkit to ensure your dashboards stay lean, responsive, and user-friendly. The goal is always the same: get to insights within 3 seconds, so your team can make data-informed decisions without friction.