The number in the admin center is three numbers
Dataverse storage stops being an abstract line on a renewal slide the day a sandbox refuses to copy or an import stalls at ninety percent. By then the tenant has been drifting toward the limit for months and nobody watched the slope. The work that prevents it takes an afternoon, and most of it is reading rather than deleting.
The admin center reports capacity in three meters rather than one pool. Database capacity covers relational rows, file capacity covers the bodies of attachments, notes and file columns, and log capacity covers audit data. A tenant can sit comfortably on two and be nearly out on the third, which is why the figure people quote rarely matches the one that triggers a block.
Each meter has its own entitlement, built from a tenant base allowance plus accruals that vary by licence and by agreement. Do not take a figure from a blog post, including this one. Read the entitlement beside the consumption in your own admin center and check the accrual terms in the documents procurement signed. If an overage already reached a bill, start with reading a true-up notice.
Open the per-table view before you guess
Guessing which tables are heavy wastes a week. The capacity page breaks consumption down by environment, and each environment opens into a per-table list sorted by size. That list is the whole investigation, and ten minutes with it beats a fortnight of speculation.
Read the top ten rows and nothing else at first. The same names come up in most tenants: Attachment, Annotation, Audit, PluginTraceLog and AsyncOperation. The business tables people assume are the problem usually sit far down. Write the top five down with their sizes and the date, because the slope between two readings tells you more than either one.
Last spring I picked up a tenant where file capacity had climbed every month for a year and the platform owner was certain email was the cause. The per-table view put Annotation first by a long way. A facilities inspection app stored the engineer's photo at full resolution, then a generated PDF containing that same photo on the same record. Four megabytes of duplication per inspection, about a hundred and forty inspections a week.
The fix took a developer half a day. The flow stopped writing the PDF, the app resized photos before upload, and a scheduled job cleared duplicate notes older than ninety days. Nobody had to argue about buying capacity, and that only happened because somebody read the list instead of guessing.
Audit is the one nobody turned off
Auditing switches on in three places. System settings for the environment, then per table, then per column. What I find most often is auditing enabled at environment level and then on every table, because a solution shipped it that way or somebody ticked a box during a security review three years ago. No retention period was ever set.
Two settings do most of the work. Retention decides how long audit rows survive before Dataverse removes them, and it can be set per table rather than for everything at once. Scope decides which columns are audited. A table audited on every column writes a row for the timestamp an integration updates on every pass.
Start by listing which tables have auditing enabled and why. The honest answer for most of them is that nobody knows. Turning auditing off for a table stops new rows but leaves the old ones, so both actions are needed and both belong in a note a future admin can find.
Trace logs and run history outlive the debugging session
Plugin trace logs are the clearest case of a temporary setting that became permanent. Someone sets tracing to All to chase a bug during a go-live weekend, the bug gets fixed, and the setting stays. Every plugin execution then writes trace rows into a table nobody opens until the next incident.
Check the plugin trace setting in every environment and put it back to Off, or to Exception if a team needs failure traces, then clear the rows already there. The same applies to flow and workflow run history, which lands in the asynchronous operation and workflow log tables. A flow firing every five minutes writes more than a hundred thousand rows a year, and the question of who owns those flows is usually unanswered.
Dataverse has bulk deletion jobs for exactly this, and they can run on a recurring schedule against a filtered set of rows. Set one up for succeeded system jobs older than a month and another for trace logs, then verify next month that they ran. A cleanup job failing quietly is a common reason the graph keeps climbing.
A dead environment still counts
Capacity is consumed at tenant level, so every environment holding a Dataverse database adds to the total. The proof of concept somebody spun up for a two-week evaluation eighteen months ago still has a database, still holds the sample data loaded into it, and still shows up in the sum. So does last year's sandbox copy of production.
Sort environments by size and by last activity date, then ask the owner of each one what it is for. Expect several with no owner at all. Deleting an environment does not hand the capacity back the same afternoon, since it sits in a recoverable state first, so run the cleanup before the month you need the space.
The longer answer is giving every new environment a stated purpose and an expiry date the moment it is created. Our guide to Power Platform environment strategy covers the request and naming process, and a capacity review is the easiest place to prove why it earns its keep.
When the audit data genuinely has to stay
The hard case is the one where audit rows are retained because a control says so. Somebody in risk or internal audit has written that changes to certain records must be evidenced for a set number of years, and capacity pressure does not change that obligation. Purging is not an option available to you.
Two things still help. Read the actual control text rather than the summary people repeat in meetings. It almost always names specific records or specific fields, not every table in the environment, and the gap from what auditing currently captures is usually large. I have watched a control covering supplier bank details used to justify auditing every column of every table in a finance environment.
Then move the retained data somewhere else and keep it provable. Dataverse long term retention moves qualifying rows out of the live tables into a retained store, and an export to your own storage through Synapse Link is another route. Agree the evidence format with the control owner in writing before anything leaves the source, and confirm how the retained store is counted under your agreement.
Put a number on the trend every month
Capacity work fails when it happens once. The tenant gets cleaned up, everyone is pleased, and eleven months later the same conversation starts because nobody watched the slope. A monthly reading of the three meters and the top five tables per environment, saved in the same place every time, turns a surprise into a forecast.
Hand that reading to whoever owns the renewal, with the growth rate and the date the current entitlement runs out at that rate. That date moves a procurement conversation further than any argument about storage hygiene. For the model underneath, what Dataverse actually is covers how tables and files are stored, and the licensing hub tracks how the meters are counted.
Open the capacity page this week, take the per-table reading for your three largest environments, and write the date beside it. If the number surprises you, it has been surprising you quietly for a long time.
