HANA table partitioning

Your HANA DB is growing steadily and is reaching the limits of some tables where partitioning is unavoidable. But there are other reasons such as increasing performance or NSE (Native Storage Extension - HANA Data Tiering) where using partitions makes sense.

Limit: 2 billion entries

The design of the SAP allows the HANA DB only 2 billion entries per partition / table (column store). With larger tables from 20GB it can make sense to partition beforehand. The delta merge takes more time for large tables/partitions and thus holds locks longer than necessary.

Wrong design

Anyone running an older system on HANA may have previously inefficient partitioning designs active. At that time it was partitioned according to the primary key. This has negative effects on performance.

Do you have customer-specific tables and no suitable design yet? We would be happy to help you with an analysis to find the optimal attribute for this.

Runtime optimization of partitioning

We support you with the maintenance and shorten the runtime of the partitioning with our optimized procedure.

  • When is the right time for an analysis?

    However, any time is possible. Regardless of whether the HANA system is being migrated or a conversion is imminent. Likewise, if the system is already running on HANA, there is always the possibility of an analysis based on the size and growth of the tables, but also in the context of performance.


    An analysis of the designs should be carried out continuously (at least once a year). We also offer this in the context of our HANA Health Checks.

  • Would you like to do a partitioning yourself but don't have a design for the table?

    We carry out the analysis together with you, taking into account the growth and parameterization of the system. You can then carry out the maintenance yourself.

  • At what point does partitioning increase my performance?

    If properly designed with your applications and users (SQL statements) in mind, partitioning pruning can occur. Complete partitions are therefore removed from the selection.


    The delta merge is accelerated because each partition has its own main and delta. This speeds up the merge process as well as the subsequent Optimize Compression run.


    Inserts can only use one CPU per column and partition. The use of multiple partitions can have a positive effect on the performance of such SQLs.

  • Do I absolutely need partitioning in the NSE context?

    No, NSE (Native Storage Extension) can also be used without partitioning. However, it is mostly combined with temporal attributes. This allows you to perfectly separate these time slices and push them out into the warm store.

  • What are typical signs that I should definitely do a partitioning?

    HANA Alerts / notification:

    ID: 17  

    Record count of non-partitioned column-store tables Determines the number of records in non-partitioned column-store tables. Current table size is not critical. Partitioning need only be considered if tables are expected to grow rapidly (a non-partitioned table cannot contain more than 2.147.483.648 (2 billion) rows).


    ID: 20 

    Table growth of non-partitioned column-store tables Determines the growth rate of non-partitioned column-store tables.


    ID: 27

    Record count of column-store table partitions Determines the number of records in the partitions of column-store tables. A table partition cannot contain more than 2.147.483.648 (2 billion) rows.


    If you receive one of these messages, you should reduce the data volume or partition it as soon as possible.

All important servicesce services for everything to do with HANA from a single source.

With our range of services, we also meet the most individual requirements.
Do you want to implement a HANA project with internal resources, but still want to protect yourself? Just bring us on at certain milestones to complement the expertise of your colleagues.
request services