Performance and Realtime
Many "performance issues" are actually a mix of three different things: slow queries, slow pages, and "why is the data not realtime?" This page separates those concerns before they get mixed together.
Why does data stop looking realtime after I enable the acceleration engine?
Because the acceleration engine speeds things up by solidifying results. It is not a switch that gives you perfectly realtime data and free acceleration at the same time.
So if source data changes and the page does not immediately reflect it after acceleration is enabled, that is usually expected behavior for the acceleration path.
I want it to stay fast but also as realtime as possible. What should I choose?
Use this rule of thumb:
| Scenario | Preferred approach |
|---|---|
| Data volume is moderate, source DB is strong enough, and latest data must be visible | Prefer direct queries |
| Cross-source logic is complex or the source DB cannot handle analytic load | Use data warehouse / data integration with scheduled sync |
| Traffic is high and repeated queries are common | Tune chart cache duration |
If your real problem is "acceleration is not realtime, but direct query is too slow," the answer is usually a better balance through data integration + execution scheduling, not forcing a single fully-realtime query path.
Why does a dashboard get slower as it grows?
The most common reasons are:
- Too many charts on one page, which increases both backend query load and frontend rendering load
- Filters with very large candidate sets, especially when they read directly from fact tables
- High-cardinality fields used as dimensions, comparison dimensions, or broad filters
- Deep Fusion / join / aggregate / merge chains
- Frequent manual refreshes that bypass cache and hit the source repeatedly
If you only see a loading spinner, do not look only at the database. Also check how many charts, filters, and interactions are packed into that page.
What should I optimize first to improve chart loading speed?
Usually in this order:
- Control the number of charts in a single dashboard
- Move filters to dimension tables instead of fact tables when possible
- Reduce direct use of high-cardinality fields in display and filtering
- Set chart cache duration appropriately
- Enable sample queries during dashboard design to improve authoring efficiency
If these basics are not done yet, it is usually too early to conclude that the problem is purely a product performance limitation.
Is a slow page load the same thing as a slow data query?
No.
- Slow query is more about the data source, SQL, datasets, and cache strategy
- Slow page load can also include asset transfer, frontend rendering, and reverse-proxy configuration
If the page feels slow before the data even renders, also check whether the reverse proxy enables HTTP/2 and gzip. That will not change query logic, but it can change the perceived load time a lot.
Further reading: