Business Central Calculate Each Company Size In Database

Business Central Database Estimator

Estimate how much of your Microsoft Dynamics 365 Business Central database is consumed by a specific company using equal-share or activity-weighted allocation. This calculator is designed for administrators, consultants, and IT leaders who need a fast planning number for storage, migrations, performance tuning, and archive strategy.

Company Size Calculator

How this estimate works

• Usable company storage = total database size minus reserved overhead.
• Equal split assumes every company contributes the same share of data.
• Weighted split assigns more storage to companies with higher transaction volume.
• The output helps with migration planning, license storage forecasting, and cleanup prioritization.
• For exact numbers, validate with SQL table analysis, telemetry, backup growth trends, and company-specific retention policies.

Estimated Results

How to calculate each company size in a Business Central database

When organizations run multiple legal entities, brands, divisions, or regional operations in one Microsoft Dynamics 365 Business Central database, a practical question appears quickly: how large is each company inside the database? The platform does not always present a simple, one-click answer at the business level because SQL storage is influenced by shared application objects, indexes, system metadata, extensions, and tables that may not map perfectly to a single company. Even so, administrators still need a reliable estimating method for budgeting, migration design, environment cleanup, and performance planning. That is exactly where a structured calculator becomes useful.

The phrase business central calculate each company size in database usually refers to estimating the amount of total database storage attributable to one company record set. In practice, there are two main approaches. The first is an equal-share model, which divides usable storage evenly across all companies. The second is a weighted model, which allocates storage according to business activity, such as posted documents, ledger entries, warehouse transactions, or combined transaction counts. Neither method replaces a deep SQL analysis, but both are strong planning tools when you need fast answers.

Why company-level size estimation matters

Knowing the approximate size of each company helps answer several operational questions:

• Which company should be archived first to reduce growth pressure?
• How much storage may be required after a merger, divestiture, or historical migration?
• Which legal entity is driving backup growth and database maintenance time?
• How should you prioritize retention policies for posted documents and historical ledgers?
• What is the likely impact of splitting companies into separate environments or databases?

For example, if your total Business Central database is 180 GB and you reserve 12% for system and non-company overhead, only 158.4 GB is treated as allocable company data. If 12 companies share that allocable storage equally, the average company estimate is 13.2 GB. However, if one company posts double the transaction volume of the others, a weighted estimate gives a more realistic planning number.

Understanding the two allocation models

1. Equal split model

The equal model is best when your companies have similar sales volume, document counts, inventory complexity, and transaction history. The formula is simple:

1. Start with total database size.
2. Subtract reserved overhead percentage.
3. Divide the remaining storage by the number of companies.

This method is fast and useful for preliminary estimates, especially in early discovery workshops or budget conversations. Its biggest limitation is that real Business Central environments are rarely perfectly balanced. A high-volume distribution company can generate many more entries than a dormant holding company, even if both sit in the same database.

2. Weighted transaction model

The weighted model is stronger when one company clearly produces more data than another. Instead of assigning every company the same storage share, you assign storage in proportion to transaction activity. A reasonable proxy can be annual ledger entries, posted sales and purchase documents, item ledger entries, warehouse entries, or a composite operational count.

In the calculator above, the selected company is compared against the average of the remaining companies. The logic is:

1. Calculate usable company storage after overhead.
2. Estimate total transaction units across all companies.
3. Give the target company a share equal to its transaction units divided by total transaction units.
4. Allocate the remaining storage across the rest of the companies.

This is not a forensic storage audit, but it is a much more realistic planning method when company activity varies significantly.

What counts as overhead in Business Central storage planning

One common mistake is treating the entire SQL database size as if it belongs to company-specific data. In reality, several components consume storage that should be treated as overhead or shared platform cost:

• System tables and metadata
• Indexes and statistics
• Extension-related tables and app structures
• Change logs, telemetry-related persistence, or integration staging tables
• Temporary staging, history, and administrative records

Because of this, many administrators reserve 10% to 20% as non-company overhead for rough estimation. The exact percentage depends on how heavily customized the environment is, the number of installed extensions, and whether indexes and historical data are particularly large.

Tip: If your environment uses many extensions, retains long posting history, or has large custom tables, use a higher overhead assumption until you can validate with actual SQL analysis.

Reference data points for storage and transaction planning

The following planning data does not represent a universal Business Central rule, but it gives realistic context for storage discussions. Database growth correlates strongly with transaction volume, retention habits, warehouse complexity, and how much history is kept online versus archived.

Planning metric	Low complexity company	Mid complexity company	High complexity company
Annual posted transactions	Under 50,000	50,000 to 250,000	250,000+
Typical storage growth pattern	Slow and stable	Moderate, review quarterly	Fast, review monthly
Archive urgency	Low	Medium	High
Best estimation method	Equal split often acceptable	Weighted strongly recommended	Weighted essential

For broader database operations context, the U.S. National Institute of Standards and Technology publishes practical guidance on security and data management controls at nist.gov. Cyber resilience and backup considerations can also be reviewed through the Cybersecurity and Infrastructure Security Agency at cisa.gov. For academic best practices around data lifecycle and stewardship, many institutions provide strong guidance, including materials from cornell.edu.

Real statistics to inform company size estimation

When planning storage, it helps to anchor assumptions in broader industry behavior around data growth and backup frequency. While these are not Business Central-specific measurements, they directly influence how you should think about ERP database sizing, retention windows, and recovery posture.

Statistic	Value	Why it matters for Business Central
2021 median cost of a data breach in the United States according to NIST-linked references and industry reporting	Millions of dollars	Shows why retaining only necessary data and structuring backup strategy matters.
CISA guidance emphasis	Routine backups and recovery validation	Faster growth means more backup storage and more restore planning complexity.
Typical enterprise data growth trend	Double-digit annual growth in many sectors	Even moderate company activity can create significant ERP storage increase over time.
Operational review cadence for active databases	Monthly or quarterly in mature IT teams	Prevents surprise expansion, poor performance, and difficult migration windows.

How to improve the accuracy of your estimate

If you want a better number than a simple equal division, use business activity signals that correlate with actual table growth. In many Business Central environments, the following sources are useful:

• General Ledger Entry counts by company
• Customer Ledger Entry and Vendor Ledger Entry volume
• Item Ledger Entry and Value Entry volume for inventory-heavy companies
• Posted sales invoice, shipment, and return counts
• Posted purchase receipt and invoice counts
• Warehouse entry counts in advanced warehousing scenarios
• Custom extension tables that are strongly tied to operational volume

If one company has 240,000 annual transaction units and the average of the other 11 companies is 120,000, the target company likely consumes about twice the storage share of a typical peer, assuming similar extension usage and retention behavior. That is why weighted allocation is often the more decision-ready model.

Additional factors that can distort the estimate

• Uneven historical depth: a company with 10 years of history may be much larger than a newly created company with the same current activity.
• Document attachments: if documents or media are stored in ways that affect SQL usage, growth can accelerate beyond transaction counts alone.
• Customization patterns: custom tables may produce large volumes for only one business unit.
• Retention policies: companies with aggressive cleanup may remain smaller despite high activity.
• Index design: indexing strategy can materially change total footprint.

Best practices for administrators and consultants

To manage Business Central database growth effectively, treat company size estimation as a recurring process instead of a one-time project. The most mature teams build a repeatable monthly or quarterly review that compares estimated company share against actual database growth, backup duration, and transaction trends.

1. Track total database size every month.
2. Record the number of active companies and any major operational changes.
3. Capture transaction volume by company from key posted tables.
4. Review overhead assumptions after extension deployments or schema changes.
5. Identify outlier companies whose growth rate exceeds revenue or transaction growth.
6. Archive or purge historical data where legally and operationally appropriate.
7. Recalculate before migrations, upgrades, and environment splits.

These steps turn the estimation process into a governance tool. Instead of reacting only when SQL storage becomes expensive or backups become slow, you can forecast pressure and make cleaner architectural decisions.

When you should move beyond estimation

A calculator is ideal for planning, but there are moments when you need exact investigation. If you are preparing a large migration, carving out one company into its own environment, facing severe performance issues, or defending a storage budget to leadership, run a direct SQL-level analysis. Look at table size, index size, row counts, and company-specific table distribution. In Business Central, some data is company-specific and some is not, so exact attribution needs technical validation.

Still, an estimate is extremely valuable. It gives project sponsors a fast decision number, helps technical teams prioritize analysis, and supports conversations around archiving, retention, and business unit separation. For many organizations, that is enough to move from guesswork to disciplined storage management.

Final takeaway

If you need to calculate each company size in a Business Central database, begin with total database size, reserve a realistic overhead percentage, and choose the right allocation method. Use equal split when company activity is broadly similar. Use weighted allocation when transaction volume differs materially across companies. Then validate the biggest outliers with direct table analysis. This approach is practical, transparent, and strong enough for many real-world ERP planning scenarios.

The calculator above gives you a fast estimate for the selected company, its likely peer average, and the portion of the database held as overhead. That makes it useful for solution architects, ERP administrators, IT finance teams, and consultants who need an actionable storage estimate right now.