Hi Team, We've observed that some of our visualisations are taking longer than expected to load. Could you please help us understand the following: 1. What are the best practices to optimise visualisation performance in GoodData? 2. Can you explain how the backend processes visualisation queries — particularly what factors impact query time? 3. Is it possible to identify which specific visualisations or metrics are contributing most to the slowness?

1. Best practices to optimize visualization performance - Optimize your database / warehouse - Use columnar engines, denormalize into wide fact tables, and avoid generic

VARCHAR(2000)

types. [[Improve performance](https://www.gooddata.com/docs/cloud/connect-data/performance/)] - Use partitioning (typically by date) so queries can prune partitions. [[Improve performance](https://www.gooddata.com/docs/cloud/connect-data/performance/)] - Use materialized views or pre-aggregated tables for heavy joins and aggregations. [[Improve performance](https://www.gooddata.com/docs/cloud/connect-data/performance/)] - Add indexes on frequently used join keys and filter columns, but only on the most impactful ones. [[DB performance](https://gooddataconnect.slack.com/archives/C04S1MSLEAW/p1770910638166619?thread_ts=1770910638.166619&cid=C04S1MSLEAW)] - Use Aggregate Awareness where appropriate - Create and register aggregate tables (e.g., daily/monthly summaries) in the LDM and assign higher precedence than detail tables so GoodData can route queries to smaller, faster datasets. [[Aggregate awareness](https://www.gooddata.com/docs/cloud/model-data/create-logical-data-model/aggregate-awareness/)] - Keep in mind it currently works for additive metrics (SUM, MIN, MAX) only. [[Aggregate awareness](https://www.gooddata.com/docs/cloud/model-data/create-logical-data-model/aggregate-awareness/)] - Model and metric design - Simplify long join paths between the fact table and filter attributes; move frequently used filter logic closer to the fact table (e.g., precomputed flags) to avoid complex multi-table joins. [[Metric join path](https://gooddataconnect.slack.com/archives/C04S1MSLEAW/p1770119121028319?thread_ts=1770119121.028319&cid=C04S1MSLEAW)] - Avoid duplicate primary keys in fact tables; they can hurt both correctness and performance. [[PK duplicates](https://gooddataconnect.slack.com/archives/C04S1MSLEAW/p1755672972624149?thread_ts=1755672972.624149&cid=C04S1MSLEAW)] - Be aware that the first metric in a table becomes the “driver” for the SQL; putting the heaviest metric first can cause timeouts. [[Metric order](https://gooddataconnect.slack.com/archives/C04S1MSLEAW/p1761532143785779?thread_ts=1761532143.785779&cid=C04S1MSLEAW)] - LDM and data source hygiene - Fix LDM mapping/validation warnings; repeated attempts to resolve mapping errors can significantly slow queries. [[LDM mapping impact](https://gooddataconnect.slack.com/archives/C04S1MSLEAW/p1741731352833269?thread_ts=1741731352.833269&cid=C04S1MSLEAW)] - Ensure the data source connection is stable and consistent across environments; intermittent or misconfigured connections can cause timeouts and retries. [[Connection issues](https://gooddataconnect.slack.com/archives/C04S1MSLEAW/p1741731352833269?thread_ts=1741731352.833269&cid=C04S1MSLEAW)] - GoodData.UI / Dashboard component - Wrap your backend with

withCaching

and use

RecommendedCachingConfiguration

to cache execution results, catalogs, and attribute calls on the client side. [[UI caching](https://www.gooddata.com/docs/gooddata-ui/latest/references/dashboard_component/improve_performance/#caching-the-backend-responses)] - This reduces repeated network calls when users navigate between dashboards in a session. [[UI perf Q&A](https://gooddataconnect.slack.com/archives/C01UR5BGAHY/p1710846999653049?thread_ts=1710846999.653049&cid=C01UR5BGAHY)] - Leverage FlexCache correctly - GoodData caches raw and final query results in FlexCache; when cache is hot, visualizations can be served with very low latency. [[FlexCache](https://www.gooddata.com/docs/cloud/connect-data/cache-management/#flexcache)] - After each ELT, invalidate caches so queries don’t keep hitting stale cached results. [[FlexCache](https://www.gooddata.com/docs/cloud/connect-data/cache-management/#flexcache)] 2. How the backend processes visualization queries & what impacts time - Execution flow & caching - For each visualization, GoodData checks FlexCache: - If a matching result exists, it returns the cached final result. - Otherwise, it runs SQL on your data source, stores raw results in cache, processes them (pivot/sort/paginate), stores final results, and returns them. [[FlexCache](https://www.gooddata.com/docs/cloud/connect-data/cache-management/#flexcache)] - Cache eviction is LRU-based; there is no TTL. [[FlexCache](https://www.gooddata.com/docs/cloud/connect-data/cache-management/#flexcache)] - Query planning - The first metric in the visualization drives the main subquery; other metrics and attributes are joined to it. A heavy first metric can lead to complex SQL and timeouts. [[Metric order](https://gooddataconnect.slack.com/archives/C04S1MSLEAW/p1761532143785779?thread_ts=1761532143.785779&cid=C04S1MSLEAW)] - Long join paths (fact → multiple dimensions) required only to evaluate metric filters (e.g.,

tier_name NOT LIKE "%@"

) can significantly increase complexity and runtime. [[Metric join path](https://gooddataconnect.slack.com/archives/C04S1MSLEAW/p1770119121028319?thread_ts=1770119121.028319&cid=C04S1MSLEAW)] - Database-side factors - Large fact tables without partitioning, missing indexes on join/filter columns, or non-optimized data types all slow down GoodData queries. [[Improve performance](https://www.gooddata.com/docs/cloud/connect-data/performance/)] - High load or queueing in the database can cause GoodData’s 30s SQL execution limit to be hit, resulting in timeouts. [[Explore timeout](https://gooddataconnect.slack.com/archives/C04S1MSLEAW/p1721144102677359?thread_ts=1721144102.677359&cid=C04S1MSLEAW)] - Workspace Data Filters (WDF) add

SELECT * WHERE <column> IN <values>

-style security filters that must run on the full column; on very large tables this is inherently heavy. [[WDF impact](https://gooddataconnect.slack.com/archives/C04S1MSLEAW/p1727967178327909?thread_ts=1727967178.327909&cid=C04S1MSLEAW)] - Concurrency & resource management - Multiple KPIs on the same dashboard can issue concurrent queries to the same database, which may block each other (e.g., in Postgres) if the DB has limited I/O or connections. [[KPI concurrency](https://gooddataconnect.slack.com/archives/C04S1MSLEAW/p1730653100571639?thread_ts=1730653100.571639&cid=C04S1MSLEAW)] - Newer behavior in GoodData cancels unfinished executions when a user triggers a new action (changing filters, swapping metrics), reducing unnecessary backend load. [[Exec optimization](https://www.gooddata.com/docs/cloud/whats-new-cloud/#theming-changes)] 3. How to identify which visualizations/metrics are slow - Use

/debug

on visualizations - Open the visualization in Analytical Designer and replace

/edit

in the URL with

/debug

. This downloads a debug file containing the exact SQL GoodData runs against your data source. [[Metric order](https://gooddataconnect.slack.com/archives/C04S1MSLEAW/p1761532143785779?thread_ts=1761532143.785779&cid=C04S1MSLEAW)] - Run that SQL directly on your database to see execution time and identify heavy joins, filters, or aggregations. - Check database logs / performance tools - Use your DB’s performance insights (e.g., RDS Performance Insights, Snowflake query history) to see which GoodData-generated queries are slow and which tables/columns they stress. [[KPI concurrency](https://gooddataconnect.slack.com/archives/C04S1MSLEAW/p1730653100571639?thread_ts=1730653100.571639&cid=C04S1MSLEAW); [Snowflake case](https://gooddataconnect.slack.com/archives/C04S1MSLEAW/p1742221070310609?thread_ts=1742221070.310609&cid=C04S1MSLEAW)] - Correlate with specific metrics / filters - Compare a slow visualization with a faster one on the same data: - Remove metrics one by one or change their order to see which metric acts as a heavy driver. [[Metric order](https://gooddataconnect.slack.com/archives/C04S1MSLEAW/p1761532143785779?thread_ts=1761532143.785779&cid=C04S1MSLEAW)] - Temporarily simplify metric filters that require long join paths (e.g., remove filters on distant dimensions) and see if performance improves. [[Metric join path](https://gooddataconnect.slack.com/archives/C04S1MSLEAW/p1770119121028319?thread_ts=1770119121.028319&cid=C04S1MSLEAW)] - Look for systemic issues - If many visualizations are slow, check for: - LDM mapping warnings. [[LDM mapping impact](https://gooddataconnect.slack.com/archives/C04S1MSLEAW/p1741731352833269?thread_ts=1741731352.833269&cid=C04S1MSLEAW)] - Data source connection problems or differing URLs/configs between environments. [[Connection issues](https://gooddataconnect.slack.com/archives/C04S1MSLEAW/p1741731352833269?thread_ts=1741731352.833269&cid=C04S1MSLEAW)] If you can share (outside this chat) one or two specific slow visualizations and their

/debug

SQL, your DB team or GoodData support can pinpoint exactly which metric, join, or filter is the main bottleneck.

Hi Sameer, if you are able to send over a link to specific dashboards or visualizations we can take a better look at what is going on and may also be able to offer some better optimization practices. You can send the links to me in a DM if you wish.