EpicorFree calculatorPDF, Excel, Word exportEpicor Kinetic

Epicor Database Growth Forecast Calculator

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.

Your numbers

txns

Labor, inventory, order and GL transactions combined.

rows

Include history, audit and log tables that each transaction touches.

bytes
60 %
15 %
5 years
GB
copies

Your results

Projected database size
318.025
Total storage with copies
1,272.1
Year 1 added data
29.3702
Gigabytes written in the first year, including indexes.
Annual growth multiplier
1.15
Total data added over horizon
198.025
Total storage in TB
1.2423

Rough sizing from averages. Measure real table growth with SQL Server size reports and include log files, attachments and tempdb separately.

Save results:

Projected database size vs years

Sweeps Forecast horizon from 1 to 10, holding your other inputs fixed.

Database sizing and archive review

Optional: we can look at your table sizes and suggest archive and index options.

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

How to use it

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.

  • 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

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

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

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.

Frequently Asked Questions

What index overhead should I use?

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?

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?

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?

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.

Netray can analyse your largest tables and recommend archive options. The forecast works fine without us.