What it does

Dataverse storage is entitled in three separate pools — database, file and log — accrued from a tenant default plus per-user licence grants plus anything bought as an add-on. Apps consume it indirectly, through the tables they write to, the attachments they store, and the auditing they trigger. Capacity is a tenant-level number with environment-level consequences.

Key facts

• Three capacity types: Database, File, Log. Attachments, annotations, any table with a file or image column, web resources and Insights "– Analytics" tables sit in file and database storage. AuditBase, PlugInTraceLogBase and elastic tables sit in log. Everything else is database.
• Overflow rules are asymmetric: spare database capacity can cover log and file overuse, spare log capacity can cover file overuse, and spare file capacity covers nothing. Being 90 GB over on file with 85 GB spare elsewhere still puts you in deficit.
• Default, production and sandbox environments count against capacity. Trial, preview, support, developer and Microsoft Teams environments show as 0 GB and don't count.
• Every environment consumes 1 GB whether or not it has a Dataverse database.
• The default environment comes with 3 GB database, 3 GB file and 1 GB log included, and the list view only shows consumption above that. Use the Details button to see actual usage.
• Warning notifications fire at under 15% remaining and again at under 5%. Admins get them weekly and can't opt out or delegate.
• 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 to an environment. Environment creation needs at least 1 GB free.
• Dataverse and finance-and-operations database capacity are displayed separately but pooled for enforcement. Same for file. Log is Dataverse only.
• DataverseSearch (formerly RelevanceSearch) is a real table in the capacity report, holding the indexes behind global search and generative AI experiences, billed at the database rate.
• Capacity can be pre-allocated per environment. Currently only soft enforcement — admins get notified above 85% of allocated capacity — plus the option to link an environment to pay-as-you-go so overage bills to Azure.
• There's no technical size limit on a Dataverse environment. The limits are entitlement limits.

When to use / skip

You don't choose to have capacity, you choose whether to model it. For anything larger than a departmental app, do the sizing: row counts, attachment volume, audit retention, and how many environments the ALM design needs. The number that catches programmes out is never the transactional data — it's attachments and audit logs, which grow linearly with usage and which nobody forecast. Skip detailed per-table modelling for small builds; do model the environment count, because every environment costs 1 GB before anyone has stored anything.

Configuration decisions

• How many environments the ALM strategy really needs, given each one is 1 GB minimum and production-type environments count against entitlement.
• Whether attachments live in Dataverse file storage or somewhere cheaper — SharePoint document location is the usual answer for high-volume attachments.
• What auditing is turned on and for how long it's retained, since audit is the fastest-growing pool on most implementations.
• Whether capacity is pre-allocated per environment or left in the tenant pool. Pre-allocation gives you containment and per-environment alerts; the pool gives you flexibility.
• Whether pay-as-you-go is linked to any environment as an overage safety valve rather than a hard stop.
• Whether Dataverse search is On or Default in each environment, given its index consumes database capacity.

Gotchas

• Turning Dataverse search off to save capacity is a bad trade and Microsoft says so explicitly. It breaks global search and every dependent generative AI experience. You have 12 hours to turn it back on before the index is deleted, after which a full re-sync takes an hour for a small org and days for a large one.
• Database usage falling while file usage rises isn't a bug. Microsoft periodically moves annotations and attachments out of database into file storage and reclaims the space.
• Index size is part of database storage. Custom Quick Find configurations on wide or high-volume tables can move the number noticeably, and admins rarely connect the two.
• Team Member licences give no per-user database, file or log entitlement, so they don't appear in the entitlement breakdown. A tenant full of Team Members has less capacity than the licence count suggests.
• The Summary tab is restricted to tenant, Power Platform and Dynamics 365 admins. Environment admins get redirected to the Dataverse tab and see less.
• Deleting an environment to recover capacity is irreversible past the recovery window, and recovery itself needs 1 GB free — which you don't have if you're in overage.

Consultant notes

• Build the capacity model in the design phase and put it in the solution architecture document. It's the artefact that makes the add-on purchase conversation a plan rather than an emergency.
• Point the client at the Power Platform Licensing Guide PDF for add-on details rather than quoting anything. Microsoft defers to it for capacity add-ons and so should you.
• Warn that going into overage blocks environment creation and copy. That's a delivery blocker, not a billing issue, and it will land in the middle of a UAT refresh.
• Set the environment-level capacity alert thresholds during handover. The weekly tenant email goes to admins who won't connect it to your project.

---

Worth another look if capacity enforcement moves from soft to hard, or when the Dataverse and Operations pooling model changes again.