Most Power Platform budgets have a line for licences and no line for storage. Storage is the one that arrives without warning, because none of it is visible from the maker portal and nobody owns it until the email lands.
Dataverse capacity is not one number. It is three meters with three different prices, and they do not behave the same way.
Three meters, three prices
US list, per gigabyte per month:
- Database — $40. Table rows, indexes, and most of what your apps write.
- Log — $10. Audit data, plug-in trace logs and elastic tables.
- File — $2. Attachments, note bodies, images, files.
Capacity only flows downhill
Microsoft lets unused capacity of one type cover a shortfall in another, but only in one direction. Database can cover log and file. Log can cover file. Nothing covers database, because it sits at the top of the chain.
That rule has two consequences people do not expect.
The first is that a tenant with 200 GB of unused file capacity and a 10 GB database shortfall is in overage, and the file surplus does nothing about it. A total tells you nothing. You have to read the three types separately, every time.
The second is that an audit log blowout can cost nothing at all for years, because a database surplus quietly absorbs it — right up until the day the database side needs that surplus back, and a problem you have had for two years turns into a purchase order in a week.
The lifecycle trap
Here is the one that stops a project rather than costing money.
Environment lifecycle operations — create, copy, restore, recover, convert a trial — require at least 1 GB free in the underlying capacity type, and they ignore borrowing entirely. Your tenant can be inside its entitlement on paper, with nothing red in the admin center, and still refuse to make a sandbox because database capacity is 400 MB from full.
It surfaces at the worst possible moment: mid-project, when somebody needs a copy of production to test a release against, usually on a Friday. The fix is a cleanup or a purchase order, and neither of those happens in an afternoon. Check that you have a spare gigabyte in each type when you plan the refresh, not on the day you need it.
Where the entitlement comes from
Two parts: a tenant default, and per-user accruals.
The tenant default is granted once, by the highest qualifying product you own. Thirty gigabytes of database for a Dynamics 365 customer engagement tenant, 20 for Power Apps Premium, 15 for Per App or Copilot Studio. It is not per environment and it does not stack — buying into a second product family does not hand you a second default.
On top of that, each licence accrues a little more. A Dynamics 365 enterprise licence adds 250 MB of database and 500 MB of file. Power Apps Premium adds 250 MB and 2 GB. Per App adds 50 MB and 400 MB. Team Member accrues nothing at all, which is worth knowing before you plan a large rollout around it. These accrual figures come from the licensing guides rather than a docs page, so treat them as a sanity check against the admin center rather than a substitute for it.
Two more details worth carrying around:
- Trial, developer, preview, support and Microsoft Teams environments report zero and never draw on the pool. Only default, production and sandbox environments count.
- The default environment gets 3 GB of database, 3 GB of file and 1 GB of log of its own before it starts drawing on the tenant pool.
What is actually filling it
Four culprits, in roughly the order we find them.
Audit logging switched on broadly. Auditing is configured per table and per column, and the usual story is that somebody enabled it at the organization level years ago to close out a compliance question nobody has revisited since. Audit data lands in log capacity at $10 a gigabyte. That sounds cheap until you remember the default log entitlement is 2 GB, and everything above it is borrowing from database. The same meter carries plug-in trace logs, so an environment left on the All setting after a go-live is filling it from a second direction.
Here is the arithmetic that gets a budget holder's attention. A hundred gigabytes of audit history costs $1,000 a month if you buy log capacity for it. If it is sitting on borrowed database capacity instead, which is what normally happens, the surplus it is eating is worth $40 a gigabyte, and buying that surplus back when you finally need it costs $4,000 a month. Forty-eight thousand dollars a year for a change log of records nobody has ever queried.
The DataverseSearch index. Dataverse search maintains its own index, and it reports under database consumption. If large text columns are indexed across a lot of tables, this runs to tens of gigabytes, and it is invisible to anyone who does not know to look for it by name.
Attachments still in database storage. Attachments and note bodies belong in file capacity at $2. In older environments, and anywhere somebody stored a base64 string in a multiline text column because it was quicker than doing it properly, they are in database at $40. Forty gigabytes of documents costs $960 a year in the right place and $19,200 a year in the wrong one, for the same bytes and the same behavior.
Integrations writing rows nobody reads. A staging table an integration writes to and never cleans up. Error rows retained forever from a flow that fails four times an hour. A middleware pattern that logs one row per API call for traceability nobody has looked at since go-live. This is the least interesting cause and the most common one.
The cleanup, biggest win first
Move attachments to file storage. A twentieth of the price for the same content. This is the biggest single win available to a Dataverse admin and almost nobody makes it until an overage email forces the issue.
Set retention, then delete. Dataverse supports long-term retention policies that move eligible rows out of live tables, and bulk delete jobs that clear them on a schedule. Both are dull. Both are cheaper than $40 a gigabyte a month, forever, which is what doing nothing costs.
Narrow the auditing. Auditing four columns on two tables is a compliance control. Auditing every column on every table is a storage bill with a compliance story attached. Decide which tables genuinely need a change history, set a retention period on the audit data, and turn the rest off.
Delete the staging data, then fix what creates it. Otherwise you are doing this again next year with a bigger number.
One practical note. The capacity figures in the admin center refresh on a schedule rather than in real time, so a cleanup does not show up as a smaller number the same afternoon. Give it a day before you decide it did not work.
To find the culprit, the consumption-by-table view under Licensing in the admin center will usually name it in about a minute. To see the same picture across every environment at once instead of clicking through them one at a time, the free PowerShell scripts will pull it.
Budget for it, then decide
Buying capacity is not automatically the wrong answer. File capacity at $2 a gigabyte is frequently cheaper to buy than to clean up: 50 GB of file storage is $100 a month, which is less than the meeting you would hold to decide what to delete. Database capacity at $40 almost never is, because it compounds. A staging table growing 3 GB a month costs $120 a month after the first month and $1,440 a month by the end of the first year, for rows nobody has ever read.
The reliable tell that a tenant has never looked at this is simple. Nobody can tell you what the three numbers are. Microsoft starts emailing your admins weekly once headroom drops under 15%, and by the time those emails begin, the options have usually narrowed to buying.
The capacity calculator models the borrowing rules and prices the shortfall, using the three numbers from your own admin center.