SAPFree calculatorPDF, Excel, Word exportSAP ECC / S/4HANA

SAP IDoc Database Growth Calculator

IDoc tables grow quietly until a Basis admin notices a database that is far larger than the business data justifies. This calculator turns daily IDoc volume, segment counts and retention into a storage figure you can use to justify archiving or a shorter online retention.

Your numbers

IDocs

Total inbound plus outbound IDocs created per day across all message types.

segments

An ORDERS IDoc with 5 items is often 20 to 40 segments, a MATMAS can be well over 50. Use your own average.

bytes

EDID4 rows carry a segment header plus a 1000 character data field. Unicode systems and compression change the real figure.

bytes
records

Each status change writes a row. Errors and reprocessing add more.

bytes
%

Secondary indexes, free space and database page overhead.

90 days

Your results

Steady-state online size
87.1718
Approximate size of IDoc tables once retention is reached.
Raw bytes per IDoc
16,000
Growth per day
0.9686
Gigabytes added per day including overhead.
Growth per 30 days
29.0573
IDocs held online
4,500,000
Space freed by cutting retention to 30 days
58.1145

Planning estimate only. Measure real sizes with DB02 or your database tools and adjust the byte inputs to match your system.

Save results:

Online IDoc storage (GB) vs retention days

Sweeps Days kept online before archiving from 7 to 730, holding your other inputs fixed.

IDoc housekeeping review

Optional: a short expert review of your IDoc volumes, retention and archiving plan.

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

How to use the calculator

Enter total IDocs per day, then the average data segments per IDoc. Pull both from WE02 or WE05 statistics, or count rows in EDIDC and EDID4 for a representative week. Adjust the stored bytes per segment if you have measured table sizes in DB02. The retention slider shows what changes if you move from keeping IDocs for a year to keeping them for a quarter before archiving.

  • Use a representative busy week, not a quiet one.
  • Count inbound and outbound together, they share the same tables.
  • Include IDocs created by test or batch loads if they are not deleted.

What the formula models

Each IDoc has one control record in EDIDC, a number of data records in EDID4 and several status records in EDIDS. The calculator sums the three, multiplies by daily volume and an overhead factor for indexes and free space, then multiplies by retention days. EDID4 normally dominates, so segments per IDoc and bytes per segment move the result most. The model is linear, so the chart is a straight line. Real systems differ because of database compression and Unicode storage.

Reading the result and acting on it

Compare the steady-state size against what DB02 shows for EDID4, EDIDC and EDIDS today. If the real tables are much larger, you have IDocs older than your intended retention. The usual remedy is archiving through archiving object IDOC in SARA, with deletion of technical IDocs that have no audit value. Agree the retention with the business and audit owners first, because some IDocs, such as invoices to authorities, may need to be retained.

Common mistakes

The most common error is ignoring status records for IDocs that fail and are reprocessed many times, which can double the status volume. Another is assuming one message type represents all traffic: master data IDocs such as MATMAS are far larger than a simple status update. Finally, teams size for averages and forget that bulk loads during a migration or cutover can create millions of IDocs in a few days.

Frequently Asked Questions

Which tables hold IDoc data?

EDIDC holds the control record, EDID4 holds the data segment records on current releases, and EDIDS holds status records. Large systems often find EDID4 and EDIDS are among the biggest tables in the database.

Can I just delete old IDocs?

Technically yes, but deletion should follow your retention policy. Archive through archiving object IDOC where you need to keep the content, and delete only technical IDocs that have no audit or legal value.

How accurate is the estimate?

It is a planning figure. Accuracy depends on your segment counts and measured bytes per row. Calibrate by comparing the output with the current size of your IDoc tables in DB02 and adjust the inputs.

Does S/4HANA change the numbers?

HANA compression usually makes stored size smaller than the raw figure, so treat the result as an upper bound for column store tables and measure actual memory and disk use for your system.

If you want IDoc volumes, error rates and table growth surfaced from your live SAP system instead of typed in, Netray can build a read-only monitoring view for your Basis team.