Because cube data is already aggregated from the start, aggregations are not performed by Spotfire when working with in-db cube data. All aggregations that need to be done (if any) are pushed down to the cube query engine. Instead, Spotfire can be used as a way to display the related combinations of measures and hierarchies configured by the cube administrator.

By taking advantage of the natural structure of the cube you can make sure that you are viewing relevant data. The free-dimensionality of Spotfire does otherwise allow you to make combinations of measures and dimensions from the cube that do not always make sense, or lead to "The expression is not valid"- messages in the visualizations.

Each time you change what is shown on the axes in a visualization based on in-db cube data, or make a selection in a hierarchy filter or a check box filter, a request is sent to the cube to provide the selected data. This means that if you make many changes in Spotfire, many requests may be sent to the database instead of just the request for the final selection.

Spotfire uses a delay of about one second in order to see if there are any additional selections made in a filter before sending the request to the database. This means that you should try to make coherent changes in filtering in a steady pace and not pause for too long while selecting various check boxes. If you pause for more than about a second, the current filter selection will be sent to the cube which will start to provide the requested data. Making additional changes to the filter will send an additional request to the database, causing a higher workload on the database, as the first request might still be running.