# Epicor Database Growth Forecast Calculator > Source: https://netray.co/tools/epicor-database-growth-forecast-calculator > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Free Tools ## Short answer Project storage needs over several years from transaction volume, row size, index overhead, growth and backup copies. ## Category epicor ## Erp Epicor Kinetic ## Audience - Epicor administrator - Database administrator - IT infrastructure ## Tool **Kind:** calculator **Inputs:** #### Transactions per day **Key:** txn **Type:** number **Default:** 20000 **Min:** 0 **Step:** 1000 **Unit:** txns **Help:** Labor, inventory, order and GL transactions combined. #### Rows written per transaction **Key:** rows_txn **Type:** number **Default:** 6 **Min:** 0 **Step:** 1 **Unit:** rows **Help:** Include history, audit and log tables that each transaction touches. #### Average row size **Key:** row_bytes **Type:** number **Default:** 450 **Min:** 1 **Step:** 50 **Unit:** bytes #### Index overhead **Key:** idx_pct **Type:** slider **Default:** 60 **Min:** 0 **Max:** 200 **Step:** 5 **Unit:** % #### Annual volume growth **Key:** growth **Type:** slider **Default:** 15 **Min:** 0 **Max:** 50 **Step:** 1 **Unit:** % #### Forecast horizon **Key:** years **Type:** slider **Default:** 5 **Min:** 1 **Max:** 10 **Step:** 1 **Unit:** years #### Current database size **Key:** base_gb **Type:** number **Default:** 120 **Min:** 0 **Step:** 10 **Unit:** GB #### Copies kept (backups, test, pilot) **Key:** copies **Type:** number **Default:** 4 **Min:** 1 **Step:** 1 **Unit:** copies **Outputs:** #### Year 1 added data **Key:** yr1_gb **Expr:** txn * 365 * rows_txn * row_bytes * (1 + idx_pct / 100) / 1073741824 **Format:** decimal **Description:** Gigabytes written in the first year, including indexes. #### Annual growth multiplier **Key:** g **Expr:** 1 + growth / 100 **Format:** decimal #### Total data added over horizon **Key:** added_gb **Expr:** yr1_gb * if(eq(growth, 0), years, (pow(g, years) - 1) / (g - 1)) **Format:** decimal #### Projected database size **Key:** db_gb **Expr:** base_gb + added_gb **Format:** decimal **Primary:** true #### Total storage with copies **Key:** total_gb **Expr:** db_gb * copies **Format:** decimal **Primary:** true #### Total storage in TB **Key:** tb **Expr:** total_gb / 1024 **Format:** decimal **Chart:** #### Projected database size vs years **Type:** line **X:** years **From:** 1 **To:** 10 **Steps:** 10 **Series:** - db_gb **Disclaimer:** Rough sizing from averages. Measure real table growth with SQL Server size reports and include log files, attachments and tempdb separately. ## Content **Intro:** Disks fill slowly and then all at once. This calculator projects database size from daily transaction volume, the rows each transaction writes, row width, index overhead and annual growth, then multiplies by the copies you keep so storage budgets are realistic. **Sections:** #### How to use it **Body:** Estimate daily transactions across labor, inventory, orders and journals. Count the rows each one writes, including history and audit tables. Enter an average row size and index overhead from your own table sizes, a growth rate and a horizon. Add your current size and how many copies exist for backups, pilot and test. The tool gives projected size and total storage. **Bullets:** - Use sp_spaceused or the largest tables report to get real row sizes. - Count attachments and document storage separately. - Include the copies that consume your SAN or cloud bill. #### The formula **Body:** Year one added data equals transactions times 365 times rows per transaction times row size times one plus index overhead, divided by bytes per gigabyte. With annual growth g, the sum over the horizon follows a geometric series, which is g to the power of years minus one, divided by g minus one. Add the current size, then multiply by the number of copies. #### Reading the result **Body:** Growth compounds, so a modest rate matters over five to ten years. The chart shows the projected size curve to help you time storage purchases or decide when to archive. If one or two tables dominate, an archive or purge policy for old history may cut the curve more than buying disks, provided you keep what auditors and customers need. #### Common mistakes **Body:** Forgetting transaction log and tempdb space, not counting pilot or test copies and assuming index overhead is zero all understate needs. Another is purging without legal review of retention rules. Check backup size and restore time too, because a database that is easy to store may still be too large to restore inside your recovery window. **Cta:** Netray can analyse your largest tables and recommend archive options. The forecast works fine without us. **Faq:** #### What index overhead should I use? **Answer:** Compare table data size to index size in SQL Server reports for your biggest tables. Sixty percent is a placeholder, and the real figure varies from table to table, especially if many custom indexes were added. #### Does this include attachments? **Answer:** No. Attachments and documents are often stored outside the database or in separate stores. Estimate them separately so they are not hidden in the transaction forecast. #### Should I plan for the cloud differently? **Answer:** Cloud storage is billed continuously, so copies and retention have a direct monthly cost. Use the horizon and copies fields to compare lease terms or storage tiers, and confirm limits with your provider. #### Can I archive old data in Epicor? **Answer:** Options depend on your version and tools, and any purge needs testing and business sign-off. Involve finance and compliance before removing history, and validate reports after the archive. ## Search terms epicor database size, epicor sql server growth, epicor database storage planning, epicor database purge archive, erp database growth forecast, epicor data retention, epicor backup storage --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json