# SAP PI/PO Message Persistence Database Growth Calculator > Source: https://netray.co/tools/sap-pi-po-message-store-growth-calculator > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Free Tools ## Short answer Estimate how big the PI/PO message persistence grows from daily messages, payload size, persisted versions and retention for successful and error messages. ## Category sap ## Erp SAP PI/PO ## Audience - SAP PI/PO developer - SAP Basis administrator - Integration architect ## Tool **Kind:** calculator **Inputs:** #### Messages per day **Key:** msgs **Type:** slider **Default:** 200000 **Min:** 1000 **Max:** 5000000 **Step:** 1000 #### Average payload size **Key:** payload **Type:** number **Default:** 25 **Min:** 0 **Step:** 1 **Unit:** KB #### Persisted versions per message **Key:** versions **Type:** number **Default:** 2 **Min:** 1 **Max:** 6 **Step:** 1 **Help:** Depends on staging and logging settings, for example before and after mapping. #### Audit log and metadata per message **Key:** overhead **Type:** number **Default:** 4 **Min:** 0 **Step:** 0.5 **Unit:** KB #### Retention for successful messages **Key:** retention **Type:** slider **Default:** 7 **Min:** 1 **Max:** 90 **Step:** 1 **Unit:** days #### Error message share **Key:** err **Type:** number **Default:** 1 **Min:** 0 **Max:** 100 **Step:** 0.1 **Unit:** % #### Retention for error messages **Key:** err_ret **Type:** number **Default:** 30 **Min:** 1 **Max:** 365 **Step:** 1 **Unit:** days **Outputs:** #### Volume written per day **Key:** daily **Expr:** msgs * (payload * versions + overhead) / 1024 / 1024 **Format:** decimal **Description:** GB per day. #### Steady-state store for successful messages **Key:** ok_store **Expr:** daily * retention **Format:** number **Description:** GB. #### Store for error messages **Key:** err_store **Expr:** daily * err / 100 * err_ret **Format:** number **Description:** GB. #### Total message store **Key:** total **Expr:** ok_store + err_store **Format:** number **Primary:** true **Description:** GB in steady state, before database overhead and indexes. #### Written per year **Key:** annual_tb **Expr:** daily * 365 / 1024 **Format:** decimal **Description:** TB written and deleted per year, which drives database redo and backup volume. **Chart:** #### Total message store vs retention days **Type:** line **X:** retention **From:** 1 **To:** 90 **Steps:** 30 **Series:** - total **Disclaimer:** Estimate only. Actual size depends on staging and logging settings per interface, attachments, compression in the database and whether the deletion and archiving jobs run. ## Content **Intro:** This calculator estimates the steady-state size of the SAP PI/PO message persistence from message volume, payload, the number of message versions stored and how long successful and failed messages are kept. Use it to size the Java schema, set retention, and explain why the database keeps growing when deletion jobs stop. **Sections:** #### How to use it **Body:** Get messages per day and average payload size from Message Monitoring in the PI/PO monitoring home (pimon) or from your monitoring tool over a normal week. Persisted versions is the number of copies of each message the Adapter Engine stores: with staging or logging switched on at several processing steps, each message can be stored more than once. Overhead covers the audit log and message header data. Set retention for successful messages, the share that end in error and how long errors are kept for reprocessing. The primary output is the steady-state store, assuming deletion runs every day. The chart shows how it scales with retention. **Bullets:** - Large payloads (PDFs, IDoc bundles) dominate: segment by interface if one is much bigger - Errors are kept longer and cost more per message than their share suggests - Annual TB written drives redo, log backups and replication load #### Where messages are stored **Body:** In a Java-only PO (AAE or AEX), messages persist in the Java schema of the AS Java database; the main tables are BC_MSG for messages and BC_MSG_AUDIT for the audit log, with logged message versions in BC_MSG_LOG. Which versions are stored is controlled by the message staging and logging configuration: global settings in the NetWeaver Administrator for the XPI Service: Messaging System, and per-interface settings in the integrated configuration from 7.31 onward. Successful messages are removed by the Delete job and can be archived by the Archive job, both configured under Background Job Processing in the Adapter Engine configuration. In a dual-stack PI the ABAP Integration Server also stores messages (SXMSPMAST and related tables), deleted by RSXMB_DELETE_MESSAGES and archived per SXMB_ADM settings. **Bullets:** - Java message tables: BC_MSG, BC_MSG_AUDIT, BC_MSG_LOG - Deletion and archiving: Background Job Processing in the Adapter Engine - ABAP stack (dual stack only): RSXMB_DELETE_MESSAGES, archiving via SXMB_ADM #### Worked example **Body:** 200,000 messages a day, 25 KB payload, 2 versions and 4 KB overhead give 200,000 x 54 KB = about 10.3 GB written a day. Kept 7 days, successful messages occupy about 72 GB. One percent errors kept 30 days add about 3.1 GB. Total about 75 GB. Raise retention to 30 days and it passes 300 GB. Switch logging on for every step of one high-volume interface, taking it to 4 versions, and daily volume almost doubles. About 3.7 TB is written and later deleted per year, which the database must log and back up. #### Why the store keeps growing **Body:** When the store grows beyond the estimate, the usual cause is that the Delete job is not scheduled, not running, or cannot delete messages because they are still in a non-final status such as delivering, holding or system error. Messages in error are not deleted until they are resent or cancelled, so a backlog of errors grows forever. Archiving that is configured but whose archive store is unreachable can also block cleanup. Check job history in Background Job Processing, cancel or resend old errors, and review logging and staging settings for interfaces that store more versions than you need for support. Treat all numbers here as estimates. **Cta:** If you want your integration team to ask PI/PO which interfaces fail and why, in plain English on your own servers, we can add a private AI layer over your monitoring data. **Faq:** #### How do I reduce SAP PO message store size? **Answer:** Shorten retention for successful messages, make sure the Delete job runs daily, cancel or resend old error messages so they reach a final status, and reduce logging and staging versions for high-volume interfaces. Archive only what audit requires. Then let the database reclaim space through its normal reorganisation. #### Which table holds PI/PO messages? **Answer:** On the Java stack, the Adapter Engine stores messages in BC_MSG with the audit log in BC_MSG_AUDIT and logged versions in BC_MSG_LOG. On a dual-stack PI, the ABAP Integration Server stores messages in SXMSPMAST and related SXMS tables. Avoid deleting rows with SQL: use the deletion jobs. #### What does staging and logging mean in SAP PO? **Answer:** Staging stores a message version at a processing step so it can be restarted from that point; logging stores a version for monitoring only. Each stored version takes space. They are configured globally in NWA and can be overridden per interface in the integrated configuration in 7.31 and later. #### Is PI/PO still the right middleware? **Answer:** SAP Process Orchestration 7.5 is in maintenance with an announced end of mainstream maintenance, and SAP's direction is Integration Suite. Many manufacturers still run PO on-prem for years. Sizing the message store correctly keeps it stable while a migration is planned. ## Search terms sap pi po integration, sap pi po middleware, sap pi po example, sap pi po api, sap po message store size, pi po message deletion job, bc_msg table size --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json