Hi @IM_01,

A metric view itself is just a semantic definition (measures + dimensions) on top of some source table. By default, queries aggregate on the fly over the source... similar to querying a normal fact table with GROUP BY. A CUBE result persisted in a table/materialised view is a physically pre-aggregated table. If your query exactly matches those groupings, it usually is faster because it’s just scanning/aggregating much less data. So yes... if you compare fully precomputed cube table vs metric view reading raw fact each time, then the cube table can be faster for those specific group-bys.

However, metric views also support precomputation. The YAML can include a materialisation section that defines one or more aggregated materialised views (for specific dimension sets), and the engine automatically rewrites queries to hit those pre-aggregations. That gives you the same kind of pre-aggregated data you’d get from a hand-rolled cube table, with the added benefit of metric definitions staying in one place. You can still query other dimension combos... only the heavy/common ones use materialisations.

The takeaway is that... If you have a small, fixed set of critical group-bys and extreme latency requirements, pre-aggregated tables (or metric-view materialisations for those combos) are the right optimisation. For interactive analytics where users slice/dice across many combinations, it’s usually better to define the metrics in a metric view and turn on materialisation for the most common/expensive group-bys, rather than maintaining your own cube tables. That way you can get essentially the same performance benefits while keeping the semantic layer clean and flexible.

Check this out if you are interested. 

If this answer resolves your question, could you mark it as “Accept as Solution”? That helps other users quickly find the correct fix.