BPC Netweaver utilizes ROLAP to store data.

ROLAP ( Relational OLAP ) uses the relational

database and generate SQL queries to calculate information at the appropriate level when
an end user requests it vs MOLAP which uses Multidimensional cubes ( Essbase)
BPC NetWeaver takes advantage of three techniques for high-performance access to data:
column stores (refer below),
in memory data base ( i.e. use of HANA, Exalytics or TM1)
massive parallel processing (MPP). use of Blade servers or Grid computing to over the
challenge of Symmetric multi processing hardware )
Column Stores
Column stores simply store data vertically as opposed to horizontally. to aggregate or drill
down on the same data, column-oriented databases are far more efficient, for the simple
reason that only relevant
columns are scanned, rather than all rows and columns. Also, data in columns usually
achieve much higher compression ratios because of their natural uniformity. For star schema
data models, column stores offer another approach to MOLAP, ROLAP and HOLAP.
Why BPC is not good for transactional data
Relational databases are row-oriented; they are born of the need to handle online
transaction processing (OLTP) volumes where business events are generally recorded and
viewed a few rows at a time. Since BPC uses the Column stores it is inherently not the
solution to record transactions. Thus the reason that even after moving to HANA it will still
not be good for transaction or event records.
Key points to note

BPC uses a relational database source, the database is designed for ROLAP use.

BPC with ROLAP (netweaver version ) is considered more scalable in handling large data
volumes, especially models with dimensions

BPC generally suffers from slower query performance as opposed to MOLAP engines, the
performance degrades when the database size grows.

BPC doesn;t creates aggregate tables, the query performance then suffers because the
larger detailed tables must be queried. This is partially remedied by adding additional
aggregate tables, however it is still not practical to create aggregate tables for all
combinations of dimensions/attributes.

Factors that impact performance of BPC

While there is no restriction on the quantum of data that BPC (Netweaver) can store the
following is recommended to keep the performance optimal

Multiple smaller applications such as Sales Planning, Production Planning, and Cost Centre Planning
etc... With a summarized Finance Cube instead of one large overall application.
Limit the number of dimensions per application to no more than 15.
Restrict the number of properties you add to a dimension.
Restrict the length of each property.
Lower the number of unique members per dimension the better. Consider using an aggregated or
group level member that is still relevant to planning. Actual data is often at a more granular level than
planning, and could be summarized during the loading of the data into BPC.
Restrict the number of hierarchies as it impacts the size of the XML file as well as the time that it
takes to process a dimension.

User access should be limited to required applications and dimensions.