An IT director we spoke with recently pulled up the Power Platform admin center in January expecting the same tired warning banner about Dataverse capacity that had been sitting there since October. It was gone. Database storage for their Dynamics 365 Finance and Supply Chain Management environment had jumped from 90 GB to 125 GB overnight, with no purchase order, no change request, and no email from their partner. The natural conclusion was that the capacity problem had quietly solved itself. Four months later, the same environment tripped a new kind of alert: a file storage overage notice, even though database usage looked flat. Nothing had been deleted or migrated. The ground underneath the numbers had simply moved.
That is roughly where most Dynamics 365 and Power Platform customers stand right now with Dataverse storage. Microsoft raised default capacity entitlements significantly in December 2025, restructured how that capacity is reported and managed, and then made a second, narrower adjustment in the spring that reclassifies certain metadata between storage types. Individually, each change is well documented. Together, they change what a capacity plan built a year ago actually means, and CIOs and IT directors who treat the December Dataverse capacity increase as a problem solved rather than a system redesigned are going to be surprised by their own admin center in a quarter or two.
What changed in Dataverse capacity this December
The default database capacity increase was substantial and varied by product. Copilot Studio, Power Apps per-app plans, and Power Automate process licenses moved from a 5 GB to a 15 GB baseline. Dynamics 365 CRM applications, including Sales, Customer Service, Field Service, and the Contact Center, moved from 10 GB to 30 GB. Dynamics 365 Customer Insights went from 25 GB to 45 GB. On the ERP side, Standard tier products including Finance, Supply Chain Management, Project Operations, Commerce, and Human Resources rose from 60 GB to 90 GB, while the Premium tier for Finance and Supply Chain Management increased from 90 GB to 125 GB. File storage roughly doubled across most of these same products, though Microsoft did not publish the same level of per-product detail it did for database capacity. Log storage was left untouched.
The more structurally important change sits underneath those numbers. Finance and Operations customers previously managed two separate storage pools: one for the Operations database and one for Dataverse. As of December, those pools merged into a single combined entitlement. For an organization that had been carefully tracking two distinct capacity ceilings, this is not a cosmetic simplification. It changes how consumption trends read, and it means a team that spent the last two years building spreadsheets or Power BI reports to track Operations and Dataverse separately needs to rebuild that tracking around a single number.
Three capacity types, not one
Alongside the entitlement increase, Microsoft has been rolling out a new capacity reporting model that separates Dataverse storage into three distinct types: database, file, and log. This is not universal yet. Organizations still on the legacy model see a single blended capacity figure, while those on the new model get per-type visibility along with a mechanism called cross-capacity-type borrowing. Under that mechanism, unused database capacity can offset a log or file overage, and unused log capacity can offset a file overage, but file capacity cannot offset shortfalls anywhere else. A tenant only registers as officially over capacity after all of that eligible borrowing has already been applied.
This matters for budget owners specifically because it changes what an overage notification actually tells you. A file storage warning on an environment that appears to have plenty of headroom in its combined number is not necessarily a sign that the tenant needs more storage overall. It may simply mean the tenant has database or log capacity sitting unused that isn’t automatically flowing to cover the file shortfall, either because the environment hasn’t moved to the new model yet or because the borrowing rules genuinely don’t apply in that direction. Before anyone approves a purchase of additional capacity, it is worth confirming which reporting model the tenant is actually on and whether the specific storage type in the alert is one that borrowing rules can even help with.
The April reclassification nobody budgeted for
In April 2026, Microsoft moved solution-aware tables and related metadata out of database storage and into file storage. Total consumption for an organization does not change as a result of this move, but the split between the two numbers does, and it does so without any corresponding change in what the organization is actually storing. A team that set a database utilization threshold as an internal early-warning trigger, say 70 percent of entitlement, may find that number drop for reasons that have nothing to do with actual data growth, while file utilization climbs for the same non-reason. Anyone reviewing a capacity trend line that spans this period without accounting for the reclassification is going to draw the wrong conclusion about whether their data growth rate is accelerating or slowing down.
Sales Premium customers got a further, separate adjustment in the same window: per-user file storage entitlement doubled from 250 MB to 500 MB, and the underlying tenant base storage figures for those environments moved as well. Microsoft’s own framing for these changes has been candid about the driver: AI-assisted features, Copilot experiences inside Dynamics 365 applications, and the broader push toward agentic workflows all generate metadata, context, and interaction history that traditional transactional storage planning never had to account for. Storage capacity planning built around transaction volume alone is now measuring the wrong thing.
What a capacity plan actually needs to do differently
None of this means the December increase was a bad deal for customers. Bigger entitlements at no additional cost are, on their own terms, a straightforward win, and organizations that were previously purchasing supplemental capacity to cover a gap that the new baseline now closes should go back and cancel or right-size that spending. The mistake is treating a larger number as the end of the exercise rather than the start of a different one.
The more durable response is to rebuild storage governance around the actual mechanics Microsoft has put in place rather than around the old assumption of one number that only ever goes up when you buy more. That starts with confirming, environment by environment, whether the tenant is on the legacy single-figure model or the new three-type model, since the two require genuinely different monitoring approaches. It continues with capturing a clean baseline now, broken out by database, file, and log where that visibility exists, so that the April reclassification and any future ones can be isolated from genuine consumption growth rather than blended into it. It also means understanding the capacity extension option Microsoft makes available once an environment crosses 80 percent utilization: a 45-day window to reduce usage or purchase additional capacity, capped at three extensions in a rolling 365-day period, which is a real safety valve but not one designed to be leaned on indefinitely. And it means deciding, deliberately and in advance rather than reactively during an incident, whether pay-as-you-go billing tied to an Azure subscription is the right overage mechanism for a given environment or whether reallocating from tenant pool capacity is preferable.
For finance and IT leaders who fund these environments, the practical takeaway is that Dataverse storage has moved from a mostly static line item to something closer to a cloud consumption model, with the reporting granularity and billing flexibility that implies, but also the volatility. That is a governance conversation as much as a technical one, and it is worth having before the next reclassification lands rather than after a budget line quietly moves for reasons nobody remembers agreeing to. At Routeget, the engagements that go smoothest are the ones where a client’s storage monitoring gets rebuilt around the new model proactively, rather than the ones where the first real conversation about it happens after an unexpected overage notice.
#Dataverse #DataverseStorage #PowerPlatformLicensing #ITGovernance #DynamicsFinanceOps #CloudCostManagement
