Why Dataverse Capacity Surprises Everyone
Power Platform licensing conversations typically focus on the obvious cost drivers: Power Apps per-user vs per-app, Power Automate per-user vs per-flow, Power BI Pro vs Premium. These are the visible line items in any Power Platform business case. Dataverse storage is the invisible accumulation cost that consistently exceeds organisations' initial budget assumptions.
The pattern is predictable. An organisation pilots Power Apps, adopts it broadly, builds several Dataverse applications, and begins deploying Dynamics 365. After 12–18 months, a storage capacity alert appears in the Power Platform Admin Centre. The alert is unfamiliar, the cost calculation is opaque, and the overage pricing is per-gigabyte at rates that are meaningfully higher than Azure Blob or SQL storage. By the time the finance team sees the bill, the organisation is already committed to the applications driving the storage consumption.
Understanding Dataverse capacity licensing before you commit to Power Platform at scale is essential. This guide explains the three storage pools, what each licence type contributes, overage pricing, and how to negotiate Dataverse capacity as part of your Microsoft EA.
The key numbers: Tenant-wide Dataverse capacity starts at 10GB database + 20GB file + 2GB log. Each Power Apps per-user licence adds 250MB database + 2GB file. Each Dynamics 365 Enterprise licence adds significantly more. Overage is approximately £0.029–0.035/GB/month for database, £0.010–0.015/GB/month for file, and £0.014–0.018/GB/month for log — at EA pricing.
The Three Dataverse Storage Pools
Dataverse uses three distinct storage types, each with its own pool, entitlement structure, and overage pricing. Understanding all three is essential because they are not interchangeable — database overage is not covered by unused file capacity.
Database Capacity
Database capacity stores structured data: the tables, records, and relationships that Power Apps and Dynamics 365 applications use for their core data model. This is the most commercially significant pool. It is the first to be exhausted in growing deployments, and its overage rate is the highest of the three pools.
Database capacity consumption grows with: the number of records in Dataverse tables (every row in every Dataverse table consumes database capacity), the schema complexity (more tables and columns contribute to metadata overhead), and Dynamics 365 deployments (which are heavily database-intensive). A Dynamics 365 Sales deployment with 100,000 lead records, 50,000 contact records, 25,000 opportunity records, and associated activities can consume 5–15GB of database capacity from data volume alone.
File Capacity
File capacity stores attachments, images, documents, and binary content associated with Dataverse records. Power Automate flows that capture document attachments route them to file capacity. Power Apps that allow image upload consume file capacity. Any Dataverse table with file columns consumes file capacity proportionally to the volume and size of content stored.
File capacity entitlements per licence are larger than database entitlements (2GB per Power Apps per-user vs 250MB database), reflecting the typically higher volume of file content relative to structured record data. However, in document-heavy workflows — particularly those involving scanned contracts, PDFs, or image collections — file capacity can be exhausted faster than database capacity.
Log Capacity
Log capacity stores audit history and plugin trace logs. Every time a Dataverse record is created, updated, or deleted, if auditing is enabled, a log entry consumes log capacity. For organisations with extensive audit requirements — regulated industries, financial services, healthcare — log capacity can grow significantly over time.
Log capacity entitlements are the smallest of the three pools. The per-licence entitlement contribution to log capacity is not explicitly published; the tenant-wide 2GB starting allocation is the primary source. Log capacity is rarely the first pool to be exhausted, but in compliance-heavy deployments with years of audit history and long retention requirements, it can become a commercial issue.
Entitlement Table: What Each Licence Contributes
Dataverse capacity entitlements are pooled at the tenant level. All per-licence contributions across all qualifying licences aggregate into the tenant's available capacity. This pooled model means that a diverse licence estate (Power Apps per-user + Power Automate per-user + Dynamics 365 licences) accumulates capacity from multiple sources.
| Licence Type | Database / User | File / User | Log / User | Notes |
|---|---|---|---|---|
| Tenant base allocation | 10 GB | 20 GB | 2 GB | Flat tenant-wide entitlement regardless of licences |
| Power Apps per-user plan | 250 MB / user | 2 GB / user | — | Pooled across all users; does not stack per environment |
| Power Automate per-user plan | 50 MB / user | 200 MB / user | — | Smaller contribution — reflects lighter Dataverse usage typical of flow-only users |
| Power Automate per-flow plan | 50 MB / flow | 200 MB / flow | — | Per-flow plan contributes per licenced flow |
| Dynamics 365 Enterprise (Sales/Service/Field/Operations) | ~250 MB / user | ~2 GB / user | ~2 GB / user | Varies slightly by D365 product; log entitlement significantly higher |
| Dynamics 365 Professional (Sales Pro/Customer Service Pro) | ~50 MB / user | ~2 GB / user | — | Lower database contribution reflects simplified D365 use case |
| Dynamics 365 Team Members | — | — | — | No Dataverse capacity contribution. Read/light-write use case only. |
| Power Apps per-app plan | — | — | — | No Dataverse capacity contribution. Capacity must come from per-user licences or add-ons in the same tenant. |
Per-app plan trap: Power Apps per-app licences do not contribute Dataverse capacity. Organisations that deploy Power Apps per-app broadly as a cost-saving measure often discover that their Dataverse capacity pool is not growing with their user base. If all Power Apps users are on per-app plans, Dataverse capacity grows only from the base allocation and any Dynamics 365 licences in the tenant. This creates an overage risk that per-user deployments would not face.
Worked Example: Calculating Your Dataverse Entitlement
Consider a 1,000-user organisation with the following Power Platform licence estate: 200 Power Apps per-user licences, 150 Power Automate per-user licences, 100 Dynamics 365 Sales Enterprise licences, and 600 M365 E3 licences (which provide access to basic Power Apps but no Dataverse entitlement contribution beyond the base allocation).
The database capacity calculation: 10GB base + (200 × 250MB Power Apps per-user) + (150 × 50MB Power Automate per-user) + (100 × 250MB D365 Sales Enterprise) = 10GB + 50GB + 7.5GB + 25GB = 92.5GB database capacity.
The file capacity calculation: 20GB base + (200 × 2GB Power Apps per-user) + (150 × 200MB Power Automate per-user) + (100 × 2GB D365 Sales Enterprise) = 20GB + 400GB + 30GB + 200GB = 650GB file capacity.
The log capacity calculation: 2GB base + (100 × 2GB D365 Sales Enterprise) = 202GB log capacity.
These totals represent the organisation's pooled entitlement. If their Dataverse applications collectively consume 110GB of database capacity, they are 17.5GB over entitlement and will face overage charges.
Overage Pricing: What It Costs When You Exceed Entitlement
When a tenant exceeds its Dataverse capacity entitlement, Microsoft charges for the overage at per-gigabyte rates. At EA pricing (typically 15–25% below list), approximate overage rates are:
| Storage Type | List Price / GB / Month | Approx. EA Price / GB / Month | Annual Cost per 100GB Overage (EA) |
|---|---|---|---|
| Database capacity | ~£0.040–0.045 | ~£0.030–0.035 | ~£3,600–4,200 |
| File capacity | ~£0.013–0.018 | ~£0.010–0.015 | ~£1,200–1,800 |
| Log capacity | ~£0.018–0.022 | ~£0.014–0.018 | ~£1,680–2,160 |
These rates appear modest per-gigabyte, but storage consumption compounds. A Dynamics 365 Sales deployment with 500 active users generating 3–5GB of new database records per year reaches 30–50GB of data accumulation within a decade. At £0.030/GB/month for database overage, 100GB of overage costs £3,600 per year — that is £36,000 over a 10-year operational lifetime, all from a single application's data growth.
The commercial risk is amplified when multiple applications share a Dataverse environment, each contributing to the shared capacity pool. An organisation that deploys both Dynamics 365 and several custom Power Apps in the same environment multiplies the consumption sources against a single capacity entitlement pool.
Add-On Capacity: The Right Way to Expand
When entitlement capacity is insufficient, organisations can purchase Dataverse add-on capacity packs. These are standalone capacity blocks available for purchase through EA or CSP, independent of per-user licence counts. The add-on options and approximate EA pricing:
| Add-on Pack | Capacity Provided | Approx. EA Price / Month | Cost vs Overage (Database) |
|---|---|---|---|
| Dataverse Database Capacity (1GB) | 1 GB database | ~£0.030–0.035/GB | Roughly equivalent to overage rate; bulk purchases may achieve lower rates |
| Dataverse File Capacity (1GB) | 1 GB file | ~£0.010–0.015/GB | Roughly equivalent to overage rate |
| Dataverse Log Capacity (1GB) | 1 GB log | ~£0.014–0.018/GB | Roughly equivalent to overage rate |
The key commercial difference between purchasing add-on capacity upfront and paying overage is predictability and negotiation leverage. Add-on capacity purchased in the EA renewal can be negotiated as a committed block at better-than-list pricing. Overage is billed at standard rates without negotiation opportunity — because it is already consumed.
Organisations that can accurately forecast Dataverse growth (through application audits and data model analysis) should include capacity blocks in their EA commitment. This converts an unpredictable variable cost into a negotiated fixed cost at a lower unit rate.
Dataverse vs Azure SQL: The Architecture Decision
One of the most commercially significant Power Platform decisions is whether to use Dataverse as the data store for custom Power Apps, or to use Azure SQL Database or Azure Cosmos DB via a custom connector. This is an architectural and commercial decision with meaningful long-term cost implications.
Dataverse is the right choice when: Power Apps integration is primary (native Dataverse connectors are simpler than custom connectors), row-level security and Dataverse's built-in security model are needed, Dynamics 365 integration requires shared data, or maker-mode (low-code) development is the primary approach.
Azure SQL or alternative data stores may be preferable when: data volume is very high (tens of millions of records), cost per GB is a primary concern (Azure SQL is significantly cheaper per GB at scale than Dataverse add-on pricing), the application requires complex relational queries that Dataverse's API handles less efficiently, or the organisation already has Azure SQL infrastructure with established governance.
The governance model differs significantly. Dataverse capacity is managed through the Power Platform Admin Centre and billed through your M365/Power Platform licences. Azure data storage is managed through Azure resource groups and billed through MACC or Azure consumption billing. For organisations with strong FinOps practices around Azure, routing Power Platform data to Azure SQL provides better cost visibility and control.
See the Power Platform licensing complete guide for the full commercial framework governing Power Platform architecture and licensing decisions.
Environment Strategy and Capacity Management
Dataverse capacity management is also an environment governance question. Microsoft allows organisations to create multiple Dataverse environments — typically separate environments for Production, UAT/Test, Development, and Sandbox. Each environment creates its own Dataverse database. Capacity entitlement is pooled at the tenant level, so all environments draw from the same pool.
The practical risk: organisations that create development and test environments with production-equivalent data volumes for testing realism are consuming capacity entitlement in non-production environments. A development environment with a copy of production data consumes the same capacity as the production environment — doubling the capacity requirement.
Effective environment governance requires: production environments receive appropriately sized capacity allocations; test and development environments use representative (not full) data sets; a maximum environment count policy prevents unchecked environment proliferation; and an environment decommission process removes abandoned environments and returns their capacity to the pool.
Governance action: Review your Dataverse environment list quarterly. Environments created for specific projects often survive long after the project ends, consuming capacity and creating security exposure. The Power Platform Admin Centre shows per-environment capacity consumption — use it as your governance baseline.
EA Negotiation Strategy for Dataverse Capacity
Dataverse capacity is an area where EA negotiation can meaningfully reduce long-term cost. Three negotiation levers apply.
Capacity block pre-commitment. If you can forecast your Dataverse growth trajectory based on application roadmap and current consumption trends, include Dataverse add-on capacity blocks in your EA commitment at renewal. Committing to 500GB of database capacity adds to your total EA commitment value (useful for volume tier positioning) and locks in the rate before consumption forces your hand. Target a 20–30% discount on list price for capacity block commitments above 1TB.
Per-user licence mix optimisation. If your Power Platform deployment is on per-app licences and you are approaching capacity limits, the commercial case for migrating to per-user licences strengthens: per-user licences contribute Dataverse capacity, per-app licences do not. Migrating 200 per-app users to Power Apps per-user at EA pricing adds 50GB of database entitlement (200 × 250MB) to your pool while the per-user licence cost may be offset by reduced per-app capacity spend. Model the three-year comparison before the renewal.
Dynamics 365 as capacity anchor. Dynamics 365 Enterprise licences contribute the highest Dataverse capacity entitlements per user (250MB database + 2GB file + 2GB log per user). If your organisation is evaluating Dynamics 365 adoption, the capacity contribution of D365 licences should be included in the business case — particularly if you are already paying Dataverse overage charges that D365 entitlements would eliminate.
For the broader Power Platform negotiation framework, see the controlling Power Platform costs guide. For Dynamics 365 licensing and its relationship to Power Platform, see the Dynamics 365 licensing complete guide.
Monitoring and Governance Tools
Microsoft provides capacity monitoring in the Power Platform Admin Centre at admin.powerplatform.microsoft.com. The Capacity page shows the tenant-wide consumption vs entitlement for all three storage pools, with per-environment breakdowns. Email alerts can be configured to notify admins when consumption approaches defined thresholds.
Power Platform CoE Starter Kit (available free on GitHub) provides enhanced capacity reporting, environment governance dashboards, and maker activity analysis. For organisations with significant Power Platform deployments, the CoE Starter Kit provides the governance visibility that the standard Admin Centre lacks.
Capacity management should be part of your monthly Power Platform governance cadence: review consumption trends, identify applications driving outsized storage growth, and project the six-month forward consumption to determine whether an EA capacity commitment is warranted before the next renewal.
Frequently Asked Questions
Does M365 E3 contribute any Dataverse capacity?
M365 E3 includes access to Power Apps and Power Automate seeded capabilities (built on SharePoint), but standard M365 E3 licences do not contribute Dataverse capacity. M365 licences that include the full Power Apps per-user plan entitlement (not the seeded M365 access) contribute capacity — but standard E3 does not include the full per-user Power Apps plan. Verify your specific licence configuration in the Power Platform Admin Centre.
What happens when we exceed Dataverse capacity?
Microsoft does not immediately disable access when capacity is exceeded. Instead, a grace period begins during which administrators receive alerts. After the grace period, new record creation in Dataverse may be blocked, or environments may be set to restricted access. The overage charges accumulate from the point of exceedance. Microsoft strongly recommends resolving capacity exceedance before it affects application availability.
Can I move data out of Dataverse to reduce storage costs?
Yes. Azure Synapse Link for Dataverse allows you to replicate Dataverse data to Azure Data Lake Storage for analytics purposes, reducing the active record burden in Dataverse. Long-term archiving of inactive records (closed opportunities, completed cases, historical transactions) to Azure reduces database consumption while maintaining audit-trail accessibility. This architectural pattern is particularly valuable for mature Dynamics 365 deployments with years of accumulated data.
Do Power Automate Desktop licences contribute Dataverse capacity?
Power Automate Desktop per-user licences (the RPA licence for attended automation) contribute the same Dataverse entitlement as the standard Power Automate per-user plan. Unattended RPA (Power Automate unattended add-on) is a per-bot/per-flow licence model and contributes capacity at the per-flow rate.