Dataverse Licensing: Capacity, Storage, and Costs for Enterprise

The Dataverse Capacity Model — How It Works

Dataverse uses a pooled capacity model: storage entitlements from each licence that includes Dataverse rights are added together at the tenant level and shared across all environments. When you have 500 Power Apps Per User licences, each providing 250 MB of database storage, you have a pooled database capacity of 125 GB (plus the base 10 GB all tenants receive). That capacity can be allocated across any Dataverse environments in your tenant — production, sandbox, development — without per-environment constraints, subject to the total pool not being exceeded.

Dataverse tracks three types of storage capacity: database capacity (structured data tables, relationships, and metadata), file capacity (file and image data stored in Dataverse), and log capacity (audit log data). Each type is tracked separately, and overage in any type generates an admin centre warning followed by environment restrictions if capacity is not addressed. Understanding the per-licence entitlements for each storage type — and how they pool — is the prerequisite for managing Dataverse costs without over-provisioning add-on capacity.

Per-Licence Dataverse Entitlements

The key Dataverse-eligible licences and their storage entitlements, which pool at the tenant level, are the starting point for any Dataverse capacity calculation. Power Apps Per User provides 250 MB database + 2 GB file storage per licence. Power Apps Per App provides 50 MB database + 400 MB file per licence per app. Dynamics 365 Enterprise applications provide 10 GB database + 20 GB file per licence. Dynamics 365 Team Member provides minimal entitlements (negligible database + file). Power Automate Premium provides 50 MB database per licence.

The practical implication is that Dynamics 365 licences are by far the highest per-unit contributors to Dataverse capacity: 500 Dynamics 365 Sales Enterprise licences contribute 5,000 GB (5 TB) of database storage — enough for most enterprise Dataverse deployments without any add-ons. Organisations that have significant Dynamics 365 deployments often have excess Dataverse capacity from their Dynamics licences that more than covers their Power Platform Dataverse requirements. Verifying this before purchasing Power Platform-specific Dataverse add-ons is the first step in any Dataverse capacity optimisation exercise.

Log storage: the underestimated cost

Dataverse log storage — used for audit log data — has a much smaller base entitlement: 2 GB per tenant plus 0.5 GB per 5 Power Apps Per User or Dynamics 365 licences. For organisations with audit logging enabled across all Dataverse environments, log capacity fills significantly faster than database or file capacity. A common pattern is organisations with substantial Dataverse database capacity who nonetheless trigger capacity warnings because log storage is exhausted. The solution is a log retention policy — configuring audit log retention to 30 or 90 days rather than indefinite retention — which prevents log capacity from growing unboundedly without reducing compliance log coverage to below the organisation's regulatory requirements.

Dataverse for Teams vs Full Dataverse

Dataverse for Teams is a version of Dataverse hosted within the Microsoft Teams environment, available to all M365 E1, E3, and E5 users without any additional licence. It provides app and flow development capabilities within Teams — canvas apps, basic automations, and simple data models — with hard capacity limits: 2 GB database per team environment and 1 million rows per table. Dataverse for Teams environments are provisioned within Teams (not in the Power Platform admin centre) and are subject to a different governance model than full Dataverse environments.

Full Dataverse — the enterprise data platform available in standard Power Platform environments — removes these limits (within the pooled capacity model described above) and adds capabilities not available in Dataverse for Teams: complex relational data models with relationships spanning multiple tables and environments, Dataverse search across entities, plugins and custom business logic in server-side code, integration with Dynamics 365 applications, the full Power Platform maker portal, and the enterprise security model (business units, security roles, field-level security). Full Dataverse requires a Power Apps licence (Per User, Per App) or a Dynamics 365 licence that provides Dataverse access.

When Dataverse for Teams is insufficient

Organisations outgrow Dataverse for Teams when any of the following occur: a Teams environment hits the 2 GB database or 1 million row limit; the app requires data relationships or queries that span multiple Teams environments; the app needs to integrate with Dynamics 365 data; the governance requirement demands Power Platform admin centre control (not available for Dataverse for Teams environments); or the security model requires field-level security or complex business unit structures. The upgrade path from Dataverse for Teams to full Dataverse requires migrating the environment — a process that involves exporting data, provisioning a standard environment with appropriate Dataverse capacity, and re-importing — and acquiring the Power Apps licence that provides full Dataverse access. Planning this upgrade proactively (when capacity limits are at 70–80% utilisation) avoids the forced scramble when limits are hit in production. For the full Power Platform licensing context, see our Power Platform licensing complete guide.

Capacity Add-Ons: When and How Much

When actual Dataverse capacity usage approaches the pooled entitlement from licences, organisations must either add licences (which add capacity as a side effect), reduce actual consumption (housekeeping, retention policies), or purchase Dataverse capacity add-ons. Add-ons are available in three storage types — Database Capacity ($40/GB/month), File Capacity ($2/GB/month), and Log Capacity ($10/GB/month) — purchased through the standard Microsoft commercial channel or as EA add-on SKUs.

The commercial decision between adding licences and purchasing capacity add-ons depends on whether the organisation needs the licence functionality or only the capacity. If Power Apps Per User licences are needed for additional users anyway, the capacity they contribute (250 MB database + 2 GB file per licence) may provide the needed capacity as a side effect at zero marginal cost. If capacity is needed but no additional user licences are required, targeted capacity add-ons at the per-GB rates above are more cost-effective. The over-provisioning pattern — purchasing capacity add-ons against usage estimates rather than validated actual consumption — is the primary waste mechanism in Dataverse licensing. Always validate the Dataverse capacity report (admin centre → Resources → Capacity) against actual add-on holdings before purchasing more capacity.

Optimisation and EA Negotiation

Dataverse capacity optimisation has three levers before purchasing add-ons. First, calculate actual pooled capacity from all Dataverse-eligible licences across the tenant — Power Apps, Power Automate Premium, Dynamics 365 — and compare against actual consumption. Organisations with Dynamics 365 deployments frequently have excess capacity from Dynamics licences that covers Power Platform requirements entirely. Second, implement data retention policies for audit logs (log capacity), file attachment housekeeping (file capacity), and Dataverse bulk delete jobs for test and development data (database capacity). Third, decommission inactive environments — each active environment retains its capacity allocation; environments that haven't been used in 90 days can typically be decommissioned, releasing capacity to the pool.

In EA negotiations, Dataverse capacity add-ons should be negotiated against validated consumption data, not estimates. Present the admin centre capacity report showing actual vs entitled consumption, calculate the net deficit in each storage type (if any), and negotiate only the add-on volume required for the validated deficit plus a conservative growth buffer (typically 20%). Microsoft's starting position will often include Dataverse capacity assumptions that exceed your actual requirement; the validated consumption report is the counter-evidence. For the full Power Platform commercial optimisation framework, see our Power Platform cost control guide and our Power Platform governance guide. For broader EA capacity and add-on negotiation tactics, see our Microsoft EA negotiation tactics guide.