Capacity and storage

What it does

Dataverse storage is metered in three separate buckets — database, file and log — pooled at tenant level and reported per environment in the Power Platform admin centre. Your entitlement comes from a tenant base allocation plus per-user licence accruals plus any add-ons, and the platform tells you off when you exceed it.

Key facts

Database holds everything that isn't a file or a log: table rows, metadata, relational data, and index files.
File holds attachments, notes, and any file or image column. Annotation and Attachment data has been progressively moved out of database into file storage, so a shrinking database figure alongside a growing file figure is expected behaviour, not a bug.
Log holds the Audit table, plug-in trace logs and elastic tables. This is the bucket that surprises people.
Dataverse search indexes are reported as a table named DataverseSearch (formerly RelevanceSearch) and are charged at the database capacity rate.
Overflow works in one direction only: spare database capacity can cover a log or file deficit, and spare log can cover file. Spare file capacity covers nothing.
Notifications fire weekly at under 15% remaining, again at under 5%, and again once you're in overage. Tenant, Power Platform and Dynamics 365 admins all get them and nobody can opt out.
In overage, these operations stop: create an environment, copy an environment, restore an environment, convert a trial to paid, recover an environment, add a Dataverse database. Several of those need at least 1 GB free.
Admins can preallocate capacity to a specific environment. Overage against a preallocated amount is currently soft enforcement only — email at 85% of allocation — but it reduces what's left in the tenant pool for everyone else.
Default, production and sandbox environments count towards consumption. Trial, preview, support, developer and Teams environments don't.
Microsoft states there's no technical limit on the size of a Dataverse environment. The numbers in the admin centre are entitlement limits, not engineering ones.

When to use / skip

This isn't optional — every Dataverse project needs someone watching the capacity page monthly, and the sooner you make that a named person the better. The real work is understanding which bucket you're growing, because the fix is different for each: log growth means your audit configuration is too broad, file growth means attachments and probably a SharePoint conversation, database growth means either genuine business volume or a table nobody has ever pruned. Don't let a client buy add-on capacity before you've looked at the per-table breakdown; more often than not it's one table, and it's usually an audit or a plug-in trace log.

Configuration decisions

Whether to preallocate capacity per environment or let everything draw from the tenant pool, which trades predictability against flexibility.
Whether to link environments to a pay-as-you-go plan so overage bills to Azure rather than blocking admin operations.
Which tables carry a retention or bulk delete policy, decided before the environment reaches 80% rather than after.
Whether Dataverse search stays on for every environment, accepting the index consumption, or is left at Default for environments that don't need generative AI experiences.
Who owns the capacity alert distribution, given the notifications go to tenant-level admins automatically and can't be delegated.

Gotchas

Turning Dataverse search off to reclaim index space is a trap. You get 12 hours to change your mind; after that the index is deleted and a rebuild can take days for a large org, during which search and every generative AI experience is degraded.
File capacity excess can't rescue a database or log deficit. Clients with piles of spare file capacity still get blocked.
The default environment's list view shows only consumption above its included quota, so it reads as 0 GB until it isn't. Open the Details pane to see actual usage.
Team Member licences give no per-user database, file or log entitlement, so they don't appear in the entitlement breakdown. Expect that question.
Environments without a Dataverse database still consume 1 GB each. Tenants with dozens of empty environments lose real capacity to them.

Consultant notes

Run the per-table breakdown at the start of any storage conversation. It converts an abstract argument about buying capacity into a specific argument about a specific table.
Warn clients that audit is the most common cause of a log capacity crisis, and that it grows in proportion to transaction volume, not data volume. Nobody expects this.
Never quote add-on pricing. Point at the Power Platform and Dynamics 365 licensing guides and let procurement do procurement.
Downloadable capacity reports expire after 30 days. If you're building a trend, capture the export on a schedule rather than trusting the portal to remember.

Revisit if the storage buckets change again, or if the soft enforcement on preallocated environment capacity becomes hard enforcement.