# S/4HANA HANA Memory Sizing Estimator

> Source: https://netray.co/tools/s4hana-hana-memory-sizing-calculator
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Free Tools

## Short answer

Rough-size the HANA database memory and persistence you will need from your current database footprint.

## Category

sap

## Erp

SAP S/4HANA

## Audience

- Basis lead
- SAP architect
- CIO

## Tool

**Kind:** calculator

**Inputs:**

#### Source database used size

**Key:** source_gb

**Type:** number

**Default:** 4000

**Min:** 0

**Step:** 100

**Unit:** GB

**Help:** Used space in the current database including indexes, from the DBA, not allocated storage.

#### Share that is indexes and free space

**Key:** idx_pct

**Type:** slider

**Default:** 30

**Min:** 0

**Max:** 70

**Step:** 1

**Unit:** %

**Help:** Row-store databases carry many secondary indexes that HANA does not need in the same way.

#### Reduction from archiving and cleanup

**Key:** cleanup_pct

**Type:** slider

**Default:** 20

**Min:** 0

**Max:** 60

**Step:** 1

**Unit:** %

**Help:** Data archived or deleted before conversion.

#### Expected compression factor

**Key:** compression

**Type:** slider

**Default:** 4

**Min:** 2

**Max:** 8

**Step:** 0.5

**Unit:** x

**Help:** Column-store compression varies by data; treat 3 to 5 as a planning range and confirm with the sizing report.

#### Annual data growth

**Key:** growth

**Type:** number

**Default:** 12

**Min:** 0

**Step:** 1

**Unit:** %

**Help:** From your own history of table growth.

#### Planning horizon

**Key:** years

**Type:** slider

**Default:** 3

**Min:** 1

**Max:** 7

**Step:** 1

**Unit:** years

**Outputs:**

#### Net data after index removal

**Key:** net_gb

**Expr:** source_gb * (1 - idx_pct / 100)

**Format:** number

**Description:** Data portion of the source database.

#### Data after archiving

**Key:** clean_gb

**Expr:** net_gb * (1 - cleanup_pct / 100)

**Format:** number

#### Compressed HANA data today

**Key:** hana_gb

**Expr:** clean_gb / compression

**Format:** number

**Description:** In-memory data footprint at go-live.

#### Compressed data at horizon

**Key:** future_gb

**Expr:** hana_gb * pow(1 + growth / 100, years)

**Format:** number

#### Suggested memory

**Key:** ram_gb

**Expr:** future_gb * 2

**Format:** number

**Primary:** true

**Description:** Rule of thumb: about half of RAM for data, half for working space.

#### Persistent data volume

**Key:** data_vol_gb

**Expr:** ram_gb

**Format:** number

**Description:** Planning figure of about 1x memory.

#### Log volume

**Key:** log_vol_gb

**Expr:** min(ram_gb * 0.5, 512)

**Format:** number

**Primary:** true

**Description:** About 0.5x memory, capped at 512 GB as a planning figure.

**Chart:**

#### Suggested memory vs compression factor

**Type:** line

**X:** compression

**From:** 2

**To:** 8

**Steps:** 13

**Series:**

- ram_gb

**Disclaimer:** Rough estimate for budgeting only. Use SAP sizing reports for your release and a certified hardware or cloud sizing for purchasing decisions.

## Content

**Intro:** Memory is the largest hardware line item in a move to HANA, and early budgets are usually guessed. This estimator walks from your current database size to a memory and disk figure in a few transparent steps so you can challenge the assumptions.

**Sections:**

#### How to use it

**Body:** Start with used database size from your DBA and estimate how much of it is index and free space. Add the share you expect to remove through archiving, then choose a compression factor. Set your measured annual growth and a planning horizon. The tool outputs compressed data today, at the horizon, and a suggested memory, data volume and log volume. Try different compression factors in the chart to see how sensitive the budget is.

**Bullets:**

- Use used space, not allocated tablespace
- Be conservative with the archiving percentage
- Run the official sizing report on the source system
- Re-run after the first test migration

#### The method

**Body:** Net data is source size minus the index and free share. Archiving reduces it further. Dividing by the compression factor gives the in-memory footprint, which is then grown by compound annual growth over the horizon. A common planning rule keeps roughly half of memory for data and half for working space such as temporary query results and delta merges, so suggested memory is twice the future data footprint. Persistent volumes follow similar planning rules. These are budget rules, not a substitute for SAP sizing guidance.

#### Common mistakes

**Body:** People forget that S/4HANA can change the data model, so some tables grow while others shrink, and they size from allocated storage rather than used. Another mistake is assuming the best compression result seen in a demo. Also remember that non-production systems, high availability and disaster recovery multiply the hardware or cloud cost. If you buy through a hosted or RISE offering, the provider sizes in set tiers, so check which tier your figure lands in.

**Cta:** Netray can help build a private assistant over your sizing reports and project documents so your Basis and finance teams get consistent answers.

**Faq:**

#### Is this a replacement for SAP sizing?

**Answer:** No. It is a budgeting estimate that exposes your assumptions. For purchasing, run the SAP sizing reports on the source system and use certified hardware or cloud sizing for the target release.

#### Why is suggested memory twice the data?

**Answer:** HANA needs working memory beyond stored data for queries, delta merges and temporary results. A planning rule of roughly half for data and half for working space is common, and your vendor may use a different ratio.

#### What compression factor is realistic?

**Answer:** It depends on your data. Many teams plan with 3 to 5 for a database moving from a row store. Treat anything higher as an upside until a test migration confirms it.

#### Does archiving really help that much?

**Answer:** Often yes, because old documents and change records can be a large share of the database. The benefit depends on retention rules and how much your auditors require to stay online.

## Search terms

hana memory sizing calculator, s4hana sizing estimate, sap hana database size from oracle, sap quicksizer alternative, hana compression factor, sap hana ram requirement, ecc to hana sizing

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json