7 Ways to Reduce Dataverse Storage Consumption
Howdang Rashid
Saturday, 22 August 2026 · 3 min read
Dataverse storage bills rarely spike - they creep. Background jobs, audit logs, emails with attachments, and old import history all grow quietly until the capacity warning lands. Here are seven cleanup methods that reclaim real space, organised by which of the three storage buckets they hit.
The full carousel with MS Learn links for every method is free in the Powercademy Success Kit.
How is Dataverse storage actually structured?
Dataverse capacity is split three ways, and each is billed and managed separately: Database (your rows - tables and records), File (attachments and files), and Log (audit and system logging). You can see the split per environment in the Power Platform admin centre - always check it first, because it tells you which of the seven methods below will actually move the needle.
What can you clean out of database storage?
1. System jobs and workflow logs. Every background run - flows, classic workflows, imports, deletes - creates records in AsyncOperationBase and WorkflowLogBase, and completed jobs never auto-delete by default. These tables grow quietly forever until you clean them.
2. Suspended workflows. Suspended jobs are workflows that hit an error and got stuck waiting. Important nuance: fix the cause first, then clean up - deleting blindly just guarantees they come back.
3. Import history. Data imports create tracking logs (ImportJobBase) behind the scenes. Do enough imports and you're paying storage for old admin activity - safe to remove once the imported data is validated.
4. Activity tables - especially email. Email can be the largest table in an environment thanks to HTML content and attachments (ActivityPointer, Email). If users treat Dataverse like Outlook, your database pays the price. This one spans both database and file storage.
5. Dataverse Search scope. Search builds an index, and indexing everything means bigger storage. Open your default solution, keep only the tables people actually search, and remove the rest.
What about log storage?
6. Audit history. Audit logs (AuditBase) track field changes, record access, and deletes - they grow fast and never shrink unless deleted. Align with your compliance requirements before pulling the trigger.
7. Audit retention. Retention controls how long logs live. "Forever" sounds safe, but it's the fastest way to burn log capacity. Shorter retention means slower growth and fewer emergency cleanups - the easiest long-term win on this list.
FAQ
Which method frees the most space fastest?
Usually the email and activity tables (method 4) for database/file storage, and audit history (method 6) for log storage. Check the capacity breakdown per table in the admin centre first - the biggest table wins.
Is it safe to delete system jobs?
Completed jobs, yes - they're history, not logic. Keep failures you're still investigating, fix the cause of suspended jobs before deleting them, and use bulk-delete jobs with filters rather than manual deletion.
Will reducing audit retention break compliance?
Not if you set it to your actual retention requirement instead of "forever". Most compliance frameworks specify a period - match it, document the decision, and export anything that must outlive the window.
What if we're still over capacity after all seven?
Then it's an architecture conversation, not a cleanup one: move attachments to SharePoint, archive cold records to a data lake, or buy capacity deliberately. At that point you're paying for data you actually use - which is fine.
The hi-res version of this guide is in the Powercademy Success Kit - free, along with hundreds of other cheat sheets, roadmaps, and guides for Microsoft professionals.