SAPFree calculatorPDF, Excel, Word exportSAP HANAAll SAP HANA and Basis tools

SAP HANA Table Partition Calculator for the 2 Billion Row Limit

A non-partitioned SAP HANA column table, and each partition of a partitioned one, can hold at most 2^31 (about 2.1 billion) rows. This calculator projects a table's growth, shows how many years are left before it hits that limit, and suggests a partition count for your planning horizon.

Your numbers

Current row count

rows

SUM(RECORD_COUNT) from M_CS_TABLES for the table.

New rows per year

rows

Net of archiving and deletion.

Years ahead

5 years

Target max rows per partition

rows

Rule of thumb often used: 100 million to 500 million.

Number of HANA hosts

Your results

Recommended partitions

Rows at horizon

2,700,000,000

Hard limit per partition (2^31)

2,147,483,648

Years until limit with 1 partition

3.2 years

Shows 0 if growth is 0 or the table is already past the limit.

Rows per partition at horizon

450,000,000

Partitions per host

In scale-out, aim for a whole number so partitions spread evenly.

The per-partition row limit is a HANA system limit. The target rows per partition is a rule of thumb, not an official SAP value; follow SAP's application-specific partitioning guidance for S/4HANA and BW tables.

Save results:

Recommended partitions vs years ahead

Sweeps Years ahead from 1 to 10, holding your other inputs fixed.

Get a partitioning plan for your largest tables

Send the M_CS_TABLES output for your top 20 tables and we will flag row limit risks and suggest schemes to discuss with SAP guidance.

Optional. The tool and every export work without this. No spam.

Was this tool useful?

How to use it

Get the current row count from M_CS_TABLES: SELECT SCHEMA_NAME, TABLE_NAME, SUM(RECORD_COUNT) AS TOTAL_ROWS, COUNT(*) AS PART_COUNT FROM M_CS_TABLES WHERE TABLE_NAME = 'ACDOCA' GROUP BY SCHEMA_NAME, TABLE_NAME. For a partitioned table each row of M_CS_TABLES is one partition, so also check the largest single PART_ID. Estimate yearly growth from the row count a year ago or from document volumes, net of archiving. Pick a target rows per partition and the number of hosts. The primary output is the partition count that keeps every partition under the target at the horizon; the chart shows how that count rises year by year.

Check the largest partition, not just the table total
Include planned data loads and migrations in growth
For scale-out, round partitions to a multiple of hosts

The limit and the method

The HANA column store has a system limit of 2^31 rows per non-partitioned table or per partition. When an insert would exceed it, the statement fails with an error stating that the maximum number of rows per table or partition has been reached, so a growing table becomes a production outage. Partitioning splits the table into separate column store partitions, each with its own limit. SAP's partitioning FAQ (SAP Note 2044468) discusses sizing and commonly cited ranges of a few hundred million rows per partition; the 500 million default here is a planning rule, not a hard rule. Too many tiny partitions hurt queries that cannot prune partitions, so do not over-partition.

HASH: even spread on a key column, good when no natural range exists
RANGE: by year or period, enables pruning and simple ageing
HASH-RANGE: multi-level, hash first then range within it

Worked example and SQL

A table with 1.2 billion rows grows 300 million a year. With one partition it hits 2^31 in about 3.2 years. Over 5 years it reaches 2.7 billion rows, so with a 500 million target you need 6 partitions of about 450 million rows each. In SQL a hash repartition looks like ALTER TABLE "SAPABAP1"."ZSALES_HIST" PARTITION BY HASH ("DOCNR") PARTITIONS 6; and a range by year like PARTITION BY RANGE ("GJAHR") (PARTITION '2020' <= VALUES < '2025', PARTITION OTHERS). Repartitioning rewrites the table, needs memory for both copies and generates heavy redo, so run it in a window and check log backup capacity first.

SAP application tables

Large S/4HANA tables such as ACDOCA (Universal Journal), MATDOC (material documents) and BALDAT (application log data) are frequent candidates. For S/4HANA and BW, do not invent a scheme with plain SQL: follow the SAP Notes for the application, and in BW use the BW-specific partitioning tools, because the application layer may expect specific partitioning columns. For BALDAT, deleting old application logs (SLG2) is often better than partitioning. Recheck M_CS_TABLES after any repartition and confirm partitions are spread across hosts in M_TABLE_PARTITIONS or M_CS_TABLES HOST column.

Frequently Asked Questions

What is the SAP HANA table size limit?

For column store tables the row limit is 2^31 rows per table if not partitioned, or per partition if partitioned. There is no practical byte limit beyond memory and disk, but a large table must fit in memory when loaded, so memory is usually the first constraint.

How do I check table size in SAP HANA?

Query M_CS_TABLES for RECORD_COUNT, MEMORY_SIZE_IN_TOTAL and ESTIMATED_MAX_MEMORY_SIZE_IN_TOTAL by SCHEMA_NAME and TABLE_NAME, summing over partitions. M_TABLE_PERSISTENCE_STATISTICS shows disk size. In ABAP systems DBACOCKPIT also lists table sizes.

Is table partitioning a Basis task?

Usually yes for technical repartitioning, but the partitioning column and scheme should be agreed with the application owners, because it affects query pruning and, for S/4HANA and BW, must follow SAP guidance. Basis runs it in a maintenance window with memory and log headroom checked.

Can I add partitions later without downtime?

Repartitioning is an online operation in recent revisions for many cases, but it is resource intensive and locks can affect writers. Plan it like a maintenance task, test on a copy, and do not wait until a table is weeks from the 2^31 limit.

If you want your team to ask which HANA tables are approaching their row limits, in plain English on your own servers, we can build that over your monitoring views.

Talk to an Expert Explore More Free Tools