SAP HANA Sizing: A Practical Guide to Memory, Workload, and Hardware Planning

SAP HANA sizing determines the memory, CPU, storage, and network capacity required for an on-premise SAP HANA system. A reliable estimate combines business workload information with measured database data and SAP’s sizing guidance.

The process should produce a documented target for the initial installation and a review method for future growth. SAP HANA cockpit and SAP HANA database explorer help administrators validate actual consumption after the system is running.

01What SAP HANA sizing covers

SAP HANA sizing covers more than the amount of physical memory installed in a host. The assessment normally includes:

• Main-memory capacity for column-store and row-store data
• Temporary working memory for SQL execution, merges, and other operations
• CPU capacity for the expected concurrency and workload
• Data-volume and log-volume storage
• Backup storage and the required backup throughput
• Network capacity for distributed systems and connected application servers
• Headroom for data growth, maintenance operations, and operational peaks

A sizing result is a planning baseline. It should be reviewed against real consumption after implementation and whenever the data model, workload, or user population changes.

02Start with workload and business inputs

Begin with the business scope and the workload that SAP HANA will support. Identify the applications, business processes, interfaces, reporting workloads, batch windows, concurrent users, and expected data-retention period.

For an SAP S/4HANA or SAP Business Suite deployment, collect the source-system information required by the applicable SAP sizing procedure. For custom applications, document table growth, query patterns, concurrency, and peak processing periods. Separate steady-state usage from temporary conversion, initial-load, and month-end requirements.

The quality of these inputs has a direct effect on the result. A sizing report based only on current database size can miss workload-driven memory and CPU requirements.

03Use SAP Quick Sizer and sizing reports

SAP Quick Sizer is the standard starting point for estimating infrastructure requirements from business and workload information. Use the relevant project inputs and retain the assumptions that produced the result.

A HANA sizing report can complement the estimate when an existing system provides measured data. Review the report’s source period, workload coverage, growth assumptions, and any adjustment factors before using its result for procurement or installation planning.

Treat the output as a capacity target rather than an unqualified hardware specification. Validate it against the applicable SAP HANA hardware and software requirements and the certified configuration information for the intended platform.

04Estimate SAP HANA memory

Memory sizing should account for persistent data, temporary execution requirements, system services, and growth. Column-store memory is a central input because compressed data size and runtime structures both affect consumption.

For an existing database, inspect column-store table information with the M_CS_TABLES view. Useful columns include MEMORY_SIZE_IN_TOTAL and RECORD_COUNT. These values help identify the largest tables, compare data volume with record counts, and detect growth patterns that deserve further analysis.

Host-level memory can be reviewed through SYS.M_HOST_RESOURCE_UTILIZATION, including HOST, USED_PHYSICAL_MEMORY, FREE_PHYSICAL_MEMORY, ALLOCATION_LIMIT, INSTANCE_TOTAL_MEMORY_USED_SIZE, and INSTANCE_TOTAL_MEMORY_ALLOCATED_SIZE. Service-level consumption is available through SYS.M_SERVICE_MEMORY, where TOTAL_MEMORY_USED_SIZE is the used-memory column.

These measurements support capacity validation, but they do not replace workload analysis. Memory used during peak statements, delta merges, loads, backups, and other operations must be considered alongside the regular baseline. For operational interpretation, see monitoring SAP HANA memory usage.

05Account for CPU, storage, and network

CPU capacity should reflect concurrent requests, calculation-intensive workloads, data loading, parallel operations, and the required response times. Memory may be the primary constraint, but insufficient CPU can still produce queueing and extended batch windows.

Storage planning should distinguish data volumes, log volumes, shared or local file systems, backup targets, and temporary working space. Evaluate capacity, latency, throughput, redundancy, and recovery objectives together. Backup storage must support the retention policy and the throughput needed to complete backups within the available window.

Distributed SAP HANA systems also require suitable network capacity between hosts and between the database system and application tiers. Network design should be assessed as part of the certified hardware configuration rather than treated as an afterthought.

06Plan for growth and operational headroom

A useful sizing target includes expected data growth, additional users, new applications, retention changes, and periodic workload peaks. Document each assumption so that later reviews can distinguish actual growth from a change in the business workload.

Reserve capacity for administrative activities such as data loads, delta merges, software maintenance, backup operations, and recovery testing. The required margin depends on the workload and service-level objectives; it should be justified in the sizing record instead of chosen as an unexplained percentage.

After installation, compare the target with measurements from SAP HANA cockpit, SAP HANA database explorer, and SQL monitoring views. A recurring review can reveal whether growth is following the original assumptions and whether additional capacity planning is needed.

07Validate the target before installation

Before purchasing or deploying hardware, confirm that the proposed configuration satisfies the applicable SAP HANA hardware and software requirements. Check processor architecture, memory configuration, storage layout, operating system, firmware, network design, and support status.

For an on-premise installation, record the selected SAP HANA revision, installation media, hostnames, instance details, storage mount points, backup destinations, and administrative responsibilities. The sizing result should be traceable to these implementation decisions.

The installation team can then use the approved target during preparation and deployment. See installing SAP HANA on-premise for the broader installation sequence and prerequisites.

08Review sizing after deployment

Post-installation validation compares planned capacity with actual behavior. Establish a baseline during normal operation and capture representative peak periods, including batch processing and reporting activity.

Review host memory, service memory, table growth, CPU utilization, storage consumption, log activity, backup duration, and system response times. Investigate sustained pressure and repeated peaks rather than reacting to a single isolated measurement.

Lifecycle planning should also preserve the assumptions and evidence behind each sizing decision. When the system changes, update the sizing record and reassess the hardware target before capacity becomes a production constraint. Administrators can use hdblcm for SAP HANA lifecycle management when the change involves supported lifecycle operations.

09A repeatable SAP HANA sizing workflow

A practical workflow is:

1. Define the applications, business processes, users, interfaces, and retention requirements.
2. Collect source-system or workload measurements.
3. Run SAP Quick Sizer with documented assumptions.
4. Produce or review a HANA sizing report when measured database information is available.
5. Estimate memory, CPU, storage, backup, and network requirements.
6. Add justified growth and operational headroom.
7. Validate the target against SAP HANA hardware and software requirements.
8. Record the approved configuration and review it after deployment.

This sequence creates an auditable connection between business demand, technical measurements, and the selected on-premise hardware.

Summary

SAP HANA sizing is most reliable when SAP Quick Sizer, measured database information, workload analysis, and certified hardware guidance are used together. Memory measurements from the documented system views help validate the plan, while CPU, storage, backup, network, growth, and operational headroom complete the capacity picture.