Dataverse: why free capacity differs

The dashboard shows plenty of free space, yet an environment cannot be restored. Or a red warning remains after cleanup. In Dataverse, this does not necessarily mean a mistaken purchase or failed deletion. Administrators often compare indicators that answer different questions.

Database, File and Log are different capacity types. An overage calculation is also different from the prerequisite for an environment operation. First identify the unavailable operation and the capacity it needs. Then choose between cleanup, retention, additional capacity and consumption billing.

This guide uses the current Dataverse capacity model. Microsoft distinguishes relational data, attachments and audit logs. Legacy storage, Dataverse for Teams and certain environment types have different considerations. A screenshot of one percentage without an environment name and capacity type is insufficient.

Three checks instead of one percentage

Separate tenant status, environment status and the requested operation. Capacity allocated to an environment helps govern usage; increasing that allocation does not create additional tenant entitlement. Use the Power Platform capacity report to examine consumption.

This is our diagnostic method. It prevents buying File capacity for a Database problem or deleting audit history to fix a table consuming another storage type.

Free File capacity cannot rescue Database

Current rules allow some deficits to be offset by unused higher-value capacity: Database can help Log and File; Log can help File. The reverse direction is unavailable. This is capacity evaluation, not moving tables or changing their data type. Microsoft documents the borrowing direction and effective deficit.

Suppose a tenant is entitled to 40 GB of Database and consumes 42 GB. File has 100 GB unused. The Database deficit remains 2 GB because File cannot cover it. Removing only excess attachments can miss the actual Database cause.

In another hypothetical tenant, Database entitlement is 20 GB and usage is 19.6 GB. Log exceeds its own entitlement by 0.3 GB. The 0.4 GB unused Database can cover that Log deficit through eligible borrowing. The design still lacks a sensible margin for further growth.

This is our arithmetic example explaining direction, not a full implementation of Microsoft's notification thresholds. Use the reported effective deficit during an incident. Do not promise the same spare capacity to additional Log and File growth simultaneously in an internal budget.

Why restoration can still be blocked

For operations such as creation, copy and restore, Microsoft specifies at least 1 GB of available capacity. The required capacity type matters; borrowing used for warnings is not universal permission to perform an operation. The capacity restrictions explicitly distinguish these assessments.

Our previous tenant has only 0.4 GB of unused Database. Even if borrowing covers the Log deficit, it does not establish the 1 GB minimum for an operation requiring it. Adding File capacity does not create that missing Database margin.

Plan capacity for restoration and testing too. A budget allowing production to consume every GB overlooks maintenance. Determine the reserve from the operations you need and environment growth; a mandatory minimum is not a recommended margin for the entire service.

Find the table before ordering capacity

Microsoft provides cleanup methods by storage type and table. The free-space guide distinguishes audit history from asynchronous process records, for example. A table name containing “log” does not establish that it consumes Log capacity.

This is not a list of immediate deletion commands. Obtain the data owner's approval for each candidate group and check application dependencies. Removing history needed for a customer claim is not a saving.

DataverseSearch is the current name of the entry previously called RelevanceSearch. Search indexes can contribute to Database usage. An application with few rows but extensive indexing cannot be assessed from its business table alone. Check indexing in the capacity report documentation.

Audit retention is not an empty-storage button

Stopping future auditing and deleting existing history are different interventions. Microsoft's audit management documentation distinguishes retention settings and log deletion. With the ordinary setting, the active retention period is stamped on new audit records; changing it does not necessarily change old records retrospectively. The documentation also describes a Security-page policy option that can apply retention to existing logs.

Before making a change, document the administration route, affected records and whether controlled deletion of old history is needed. “We set ninety days, therefore older logs are gone” needs a verified result, not a settings screenshot.

A hypothetical business generates 0.2 GB of audit data per week and limits future retention with a new rule. Its existing deficit might still persist too long. Separate remediation of already consumed capacity from limiting future growth. This number illustrates planning; it does not estimate your environment's usage.

Long-term retention changes usability

Dataverse long-term retention keeps data for limited read access. It cannot return to the active application state. The environment holding the policy must be a Managed Environment; policy definitions can remain disabled if this requirement is unmet. Audit and elastic tables are unsupported, and file attachment savings are not guaranteed.

Microsoft describes an average 50% reduction in Database consumption for retained data; the actual result depends on the data. That does not promise that retaining half the rows halves the whole tenant. Reports include inactive data that remains retained, and reported savings take additional time to appear.

Ask whether the company only needs to read closed cases or must reopen and process them in the original application. In the latter case, the irreversible move to retention can prevent the desired workflow. Test retained-data access and relationships on a small sample first.

Managed Environments also affect licensing. Verify user entitlements before enabling the feature; see Power Apps in Managed Environments.

Read sandbox restrictions with their conditions

The documentation describes upcoming Dataverse Storage Validation. It does not prove that every described restriction is already active in your tenant. Microsoft refers to rollout information in Message center. In the documented scope, unresolved overage leads to sandbox administration mode after thirty days and disablement after ninety days; data remains retained.

Production environments, sandboxes with active pay-as-you-go and tenants with Finance & Operations have stated exclusions from this mechanism. Exemption from disablement neither adds capacity nor proves that environment-operation prerequisites disappear. Check the precise Microsoft scope.

For your service, record actual feature activation and the start of effective overage. “CRM stops after ninety days” confuses environment type, rollout conditions and the specific mechanism. Do not present it to management as an outage date without verifying those conditions.

Cleanup, purchase or pay-as-you-go

Cleanup makes sense when unnecessary data can be identified and its removal releases the capacity type in deficit. Additional capacity makes sense when necessary data grows steadily and budget predictability matters. Pay-as-you-go can help isolate variable usage, but it needs an accountable Azure billing owner.

Dataverse governance policies provide data lifecycle controls. Review selection criteria, relationships and business process impact. Adding capacity without addressing growth buys time; deleting data without ownership creates another incident.

For a quote, prepare current entitlement, actual usage by type, monthly growth, environment inventory and the required reserve. Include planned restores, copies and new environments. This is more precise than “add ten GB”.

Verify the result after remediation

1. Preserve the original report and specific error.
2. Perform the approved intervention on the identified capacity type.
3. Check fresh consumption and effective deficit; do not confuse an environment allocation with a purchase.
4. Repeat the originally blocked operation once its prerequisites match available capacity.
5. Track the banner separately. Microsoft describes approximately daily capacity evaluation and a separate banner refresh cycle that can take up to seven days.

This avoids another purchase merely because a warning refreshes slowly. It does not justify ignoring an actual operation error. Close the incident using both the fresh report and the outcome of the requested task.