Dataverse capacity and add-ons for a service tenant

What it does

Dataverse storage is sold as three separate tenant-level pools — database, file and log — with entitlements accruing from your subscriptions and per-user licences. Customer Service deployments consume all three unevenly, and the pool that runs out first is almost never the one people planned for.

Key facts

Database capacity holds table rows, metadata and search index files. File capacity holds the Attachment and AnnotationBase tables, custom tables with file or image columns, web resources, and analytics tables (those whose names end in -Analytics). Log capacity holds AuditBase, PluginTraceLogBase, elastic tables and Dataverse search indexes.
The default environment comes with 3 GB database, 3 GB file and 1 GB log. Everything beyond that comes from subscription and per-user accruals defined in the licensing guide — figures that differ by SKU and by agreement age, so read the tenant's own numbers rather than a published table.
Read the real position in the Power Platform admin center under Licensing > Capacity add-ons, which has Summary, Dataverse, Microsoft Teams, Add-ons and Trial tabs. Tenant admin, Power Platform admin or Dynamics 365 admin is needed to see it.
Add-on SKUs are named Dataverse Database Capacity, Dataverse File Capacity and Dataverse Log Capacity, bought from the Microsoft 365 admin center Marketplace by a Billing admin, in terms from one month to three years.
Capacity types can offset each other in one direction only: database can cover log or file overage, log can cover file overage. File cannot cover anything, and database overage cannot be offset at all.
Admins get weekly emails at 15% capacity remaining, again at 5%, and once entitlements are exceeded.
Going over capacity does not suspend the service and does not put data at risk, but it blocks the operations you need most in a project: create, copy, restore or recover an environment, convert a trial environment to paid, and add a Dataverse database to an environment. Each needs at least 1 GB free.
A 45-day capacity extension can be self-served from Licensing > Dataverse > Summary. It grants an extra 25% based on current usage, applies per capacity type, and can be used a maximum of three times per account.
Microsoft states the obligation plainly: you are expected to buy capacity for what you consume, and service suspension with reasonable notice remains on the table.

When to use / skip

Everyone has to plan this; the question is how much effort it deserves. A small internal helpdesk on Enterprise seats will sit comfortably inside its accrued entitlement for years, and a detailed capacity model is wasted effort. Do the sums once and move on.

A high-volume contact centre is a different animal. Case-heavy deployments with email attachments, auditing switched on broadly, conversation transcripts and analytics tables can eat file and log capacity fast, and log is the pool that surprises people because auditing is enabled with good intentions and never reviewed. If the client handles thousands of interactions a day, build a capacity model in discovery and revisit it at go-live plus three months.

The 45-day extension is a procurement bridge, not a plan. Using it because you knew you were short is fine. Using it because nobody was watching is how you find out the hard way that you cannot copy production into a sandbox.

Configuration decisions

What gets audited, on which tables and columns, and how long audit data is retained — the single biggest lever on log capacity.
Where attachments live: Dataverse file storage, SharePoint integration, or Azure Blob. This is much cheaper to decide before go-live than after.
Retention and bulk delete policy for resolved cases, closed conversations and transcript data, including who owns running it.
How many sandbox copies of production you keep, since each one consumes capacity against the same tenant pools.
Whether plugin trace logging is on in production, and whether anyone remembers to turn it off after an incident.
Whether the answer to a shortfall is an add-on purchase or a clean-up exercise, and who has the budget authority either way.

Gotchas

Capacity is tenant-wide but the pain is environment-shaped. Another team's Power Apps project can consume the headroom you were relying on for a production restore.
The blocked-operations list is the real bite. Discovering you cannot restore an environment during an incident because the tenant is over capacity is a bad afternoon.
Deleted records do not free capacity until the bulk delete has actually run and completed. Clients delete, refresh the admin center, and conclude nothing happened.
Log capacity is the quiet one. Broad auditing plus plugin trace logs left on will consume it faster than case data consumes database.
Analytics tables count against file capacity, which is counter-intuitive to anyone who assumes analytics means database rows.
The offset hierarchy only flows one way, so spare file capacity is worth nothing when database is the pool you have exhausted.
Trial environments have their own capacity view, and converting a trial to paid needs at least 1 GB free tenant-wide — a common blocker at exactly the wrong moment.

Consultant notes

Screenshot the Licensing > Capacity add-ons summary at the start of the engagement and again at go-live. It is the cleanest evidence of what the project consumed.
Make sure the client's Power Platform admin actually receives the threshold emails. In most tenants they go to an unmonitored shared mailbox.
Agree the attachment strategy in design, not build. Retro-fitting SharePoint or Blob storage for case attachments after go-live is a migration project nobody funded.
Tell the client that auditing is a capacity decision as well as a compliance one, and get them to name the tables that genuinely need it.
Check free capacity before any environment copy, restore or trial conversion you have scheduled. One minute of checking beats a blocked release window.

Worth another look after the next release wave, or if Microsoft changes the accrual model or the extension allowance.