SAP HANA Memory Sizing Calculator
Before you request hardware or a cloud instance for SAP HANA you need a defensible first number. This calculator turns used database size, compression, growth and work space into a RAM, data volume and log volume estimate you can take into a sizing conversation.
Your numbers
Used data size on the current anyDB or HANA system, not allocated disk.
Typical anyDB to HANA column store ratios fall in this range. Use the SAP sizing report result when you have it.
Dynamic memory for queries, joins and delta merges, expressed as a multiple of static data memory.
Your results
Rough planning estimate only. Final sizing must come from SAP Quick Sizer, the SAP sizing reports (for example the HANA memory sizing report for your source system) and your hardware vendor's certified appliance or TDI configurations.
Recommended RAM (GB) vs planning horizon
Sweeps Planning horizon from 0 to 10, holding your other inputs fixed.
Get a sizing review of your SAP landscape
Send your inputs and get a short written review of the assumptions from a practitioner. Optional, the calculator works without it.
Optional. The tool and every export work without this. No spam.
How to use the calculator
Enter the used data size of the source database, not the allocated disk. Pick a compression ratio that matches your data profile, set annual growth and a planning horizon, then choose a work space factor. The result shows today's static memory, the static memory after growth, and the recommended RAM. The chart sweeps the planning horizon so you can see how many years a given appliance size will last before you must scale up.
- Use used data, not allocated tablespace or file system size
- Take compression from the SAP sizing report if you have run it
- Keep growth realistic, 10 to 20 percent is common for transactional systems
- Compare the RAM result against certified node sizes, not raw GB
The method behind the numbers
HANA stores most data in compressed column format in memory, so static data memory is roughly source size divided by compression. HANA also needs dynamic memory for intermediate results, so total RAM is static data multiplied by one plus the work space factor, plus a fixed allowance for code, stacks and the operating system. For persistence, SAP guidance for the data volume is about 1.2 times RAM, and for the log volume about half of RAM up to a cap of 512 GB. These are planning rules, not guarantees.
Worked example
A 2,000 GB source with 4 to 1 compression gives 500 GB of static memory today. At 15 percent growth over 3 years that becomes about 760 GB. With a work space factor of 1.0 and 64 GB of overhead, recommended RAM is about 1,584 GB, so you would look at a 2 TB node. Data volume would be roughly 1.9 TB and log volume 512 GB. Change the factor to 0.5 and the same system fits a 1.5 TB class node, which shows how sensitive the answer is to that one assumption.
Common mistakes
The biggest error is sizing from allocated disk, which can be double the used data. The second is assuming the same compression for every table: large cluster or pool tables, LOB data and already compressed attachments behave differently. Finally, many teams forget that a migration to S/4HANA changes the data model, so the old database size is only an input to the official sizing, not a substitute for it. Treat this tool as the quick estimate before the formal exercise.
Frequently Asked Questions
Is this the official SAP HANA sizing?
No. It is a quick planning estimate. Official sizing comes from SAP Quick Sizer, SAP sizing reports run on your source system, and your hardware or cloud provider's certified configurations. Use this tool to sanity check those results and to build a budget range early.
What compression ratio should I use?
Many transactional systems land between 3 to 1 and 5 to 1 when moving from a traditional database, but results vary with data type. Run the SAP sizing report on the source system for a real number and use the closest option here.
Why is log volume capped at 512 GB?
The common SAP guidance sets the log volume at half of RAM for smaller systems and a fixed 512 GB for larger ones, since log usage depends on write throughput and not on total memory. Confirm against the current SAP note for your release.
Does this cover BW/4HANA or data warehouse workloads?
It is better suited to transactional suite workloads. Warehouse systems have different warm and cold data patterns, different work space needs and often use extension nodes, so use the dedicated SAP sizing guidance for them.
If you want sizing inputs pulled straight from your SAP system tables with a read-only, on-prem assistant that shows its queries, Netray can help set that up.
Related Tools
SAP Transport Import Window Calculator
Estimate how long a queue of transport requests will take to import and how many fit inside your production change window.
SAPSAP Background Job Capacity Calculator
Estimate batch window utilisation, elapsed time and how many background work processes you need to finish nightly jobs.
SAPSAP Dialog Work Process Estimator
Estimate dialog work processes from named users, concurrency, requests per minute and average dialog processing time.