3798406 - Performance difference: Consuming Data via the OData API on the analytic model is slower than on the underlying fact view in SAP Datasphere

When Consuming Data via the OData API, the OData request via an analytic model responds significantly slower than relational consumption on the underlying graphical view, although the model adds no additional logic.

SAP Datasphere

1. Run a relational consumption OData query against the base graphical view using the same filters and a large $top value.
2. Run an analytical consumption OData query against the analytic model with equivalent filters and the same $top value.
3. Compare response times; observe that the analytical path is significantly slower despite similar payload sizes.
4. Repeat both queries multiple times; confirm the difference persists and is not explained by temporary caching.

The performance difference is as expected due to the following reasons:

• The analytical consumption path runs through the multidimensional (MDS) layer, which builds an OLAP cube and serializes an analytical JSON response, adding overhead compared to relational row-set streaming.
• The physical database plan (reading and aggregating the fact data) is identical between both paths; the extra time is spent above the database in cube construction, sorting, and response creation.
• Large result sets (many tuples/dimensions) increase MDS cube-building and serialization time.

1. Consider the payload size. Options:
   • Page from MDS (lower RowTo) if the UI paginates anyway.
   • Reduce the row axis if not all dimensions (or all measures) from the analytic model are needed.
2. If you simply would like to extract the view data, do not use an analytic model, but the fact view.

Consuming Data via the OData API

datasphere, odata, analytical odata, relational odata, analytic model, graphical view, performance, slow, mds, hex, olap cube, cache, pagination, payload size, json serialization , KBA , DS-BB-ODATA , To address issues related to Odata consumption API , Problem