Dataverse storage capacity full? Find the culprit and free real space

A full tenant blocks the boring things first — restores, copies, new environments — and the banner never says what is full. The fix starts with reading the report correctly, because Dataverse has three storage types with separate meters.

Read the report first

In the Power Platform admin center, open Licensing > Dataverse. You get entitlement and consumption for database, file and log storage, the environments and tables consuming most, and — where it has rolled out — the storage advisor with per-table cleanup estimates.

Borrowing only flows downhill: database can cover log or file overages, log can cover file — never the reverse. A database deficit can't be papered over by spare file capacity, which is why "we still have 40 GB free" and "we're in overage" can both be true.

Pause animation

1. 1Open Licensing › Dataverse
2. 2Check database, file, log separately
3. 3Apply the borrowing rule
4. 4Target the type in deficit

The usual suspects

Microsoft's own cleanup catalogue names the tables that balloon. The highest-yield, lowest-regret targets:

• Workflow and async job history (WorkflowLogBase, AsyncOperationBase) — recurring bulk deletion jobs for completed system jobs and flow history.
• Email attachments and notes with attachments (Attachment) — file storage's biggest eater; bulk-delete by age via Advanced Find or a bulk deletion job.
• Audit logs (AuditBase) and plug-in trace logs (PluginTraceLogBase) — log storage; delete old partitions and set trace logging deliberately.
• Duplicate detection and import job leftovers, old bulk delete job records themselves, and bloated activity tables.
• Dataverse search — drop tables and columns nobody searches from the index.

Set the keepers as recurring bulk deletion jobs; a one-off purge just schedules the next crisis.

What cleanup really returns

Two documented expectations to carry into the status meeting:

• The capacity report can take up to 72 hours to reflect deletions — judge a cleanup after the weekend, not after an hour.
• Consumption includes metadata and encryption overhead, so removing 10 MB of rows doesn't reduce usage by exactly 10 MB. Upgrades and other platform operations can even bump reported usage temporarily.

Also normal: database shrinking while file grows, because Microsoft migrates attachment-like data from database to cheaper file storage over time.

When buying is the answer

If the deficit survives honest cleanup and long-term retention, Microsoft's remediation list is explicit: buy the storage type in deficit (file capacity cannot fix a database deficit), size it as deficit + expected growth + buffer − cleanup not yet reported, or link the environment to pay-as-you-go so storage bills through Azure — the pragmatic route when demand is spiky or isolated to one environment. Deleting genuinely unused environments remains the cheapest capacity there is.

Sources

• Dataverse capacity-based storage details — Microsoft Learn
• Free up storage space — Microsoft Learn
• Storage management in Dataverse — Microsoft Learn
• Delete bulk records — Microsoft Learn