Dataverse Capacity and Licensing, Structurally

Any article quoting Dataverse prices is wrong within a year, and the ones that quote entitlements in gigabytes go stale faster still. What does not change is the shape of the model — and the shape is what should influence a design, because the design is what you cannot cheaply revisit.

This covers that shape, and points at the current figures rather than reproducing them.

Two independent questions

Dataverse cost has two parts that people routinely conflate:

1. Access. Who is licensed to use applications built on Dataverse.
2. Capacity. How much storage the tenant holds, and whether it is enough.

They are billed separately and they grow for different reasons. A team can be fully licensed and still be over capacity, and a tenant can have plenty of capacity while nobody is licensed to build anything.

Access licensing, structurally

There are three tiers to be aware of, in increasing order of what they permit:

• What a Microsoft 365 subscription includes. Standard connectors, and customisation of the apps included with the subscription. It does not include general Dataverse use or premium connectors, and this is the boundary most projects discover late.
• Per-app licensing. A licence that entitles one user to run one application. Sensible when a small number of people use a small number of applications.
• Per-user licensing. A licence entitling one user to run unlimited applications. Sensible once a person uses more than a couple.

There is also a free plan for development, intended for building and testing rather than for production use by other people.

The practical consequence for architecture: if a solution will be used by a large population of occasional users, licensing may dominate every other cost, and that can legitimately change the design — a Power Pages site, a Teams-embedded experience, or SharePoint lists may be the right answer for a wide audience even when Dataverse is technically better.

Capacity, and the three kinds

Tenant capacity is pooled and comes in three distinct types. They are not interchangeable, and confusing them produces the surprise.

Type	Holds	Grows because of
Database	Table rows, relationships, indexes, and metadata	Row volume, and wide tables with many columns
File	Attachments, notes, and file and image columns	Documents attached to records — usually the largest and least expected
Log	Auditing data	Auditing enabled broadly, with no retention policy

Database capacity is the most expensive per unit of the three, which is why the two design decisions below matter so much.

The two decisions that determine cost

1. Where documents live

Attaching documents directly to Dataverse records consumes file capacity, and it is the single most common cause of unexpected consumption. The alternative — storing documents in SharePoint and using the document-management integration, so records link to a SharePoint location rather than holding the bytes — moves that storage to where it is cheaper and where the collaboration features already are.

This is a design decision, not a settings change: retrofitting it after thousands of records carry attachments is a migration.

2. What is audited, and for how long

Auditing is genuinely valuable and it is not free. Auditing every column on every table with no retention policy produces log capacity growth that nobody notices until a warning arrives.

Audit what has a reason to be audited, set a retention period, and revisit it. Turning it on everywhere "just in case" is how the majority of log-capacity problems begin.

What happens when capacity runs out

This is worth knowing before it happens, because the consequences escalate rather than arriving all at once. Warnings come first; sustained over-consumption restricts what can be done in the environment — creating environments, copying them, and eventually other operations.

The important operational point is that it is a tenant-level pool. One team's bulk import can affect another team's ability to create an environment. That makes capacity monitoring a shared administrative responsibility rather than something each project watches for itself.

Common mistakes

• Assuming Microsoft 365 licensing covers Dataverse. It does not, and this is discovered late more often than any other licensing fact.
• Attaching documents to records by default. File capacity grows fastest, and it is a design decision, not a setting.
• Auditing everything. Log capacity, with no upper bound and no retention.
• Designing for a wide audience without costing the licences. The technical design can be right and still be the wrong answer.
• Never checking capacity reports. The Power Platform admin centre reports this; nobody looks until a warning arrives.
• Storing large text in the database. Long text columns are database capacity, which is the most expensive kind.

Troubleshooting a capacity surprise

Symptom	Where to look
File capacity growing quickly	Attachments and notes on the highest-volume table; consider SharePoint integration
Log capacity growing quickly	Which tables and columns have auditing on, and whether a retention period exists
Database capacity growing quickly	Row counts by table, and whether any table holds long text that belongs in a file
Cannot create a new environment	Tenant-level capacity, not the environment you are in
Consumption higher than the row count suggests	Indexes and metadata count too; very wide tables cost more per row than expected

Frequently asked questions

What do the plans currently cost?

Check the Microsoft Power Platform licensing documentation and pricing pages. Any figure printed in an article — including this one — has a short shelf life, and licensing is exactly the area where being a year out of date changes a decision.

Is capacity per environment or per tenant?

Pooled at tenant level, consumed by environments. That is why one project's import can constrain another's.

Does deleting records free capacity immediately?

Not instantly — reporting lags, and deleted records may be retained for a period before space is reclaimed. Plan a clean-up with that lag in mind rather than expecting an immediate result.

Should I use Dataverse or SharePoint lists?

Decide on capability first: relationships, row-level security, server-side logic and transactional integrity are what Dataverse gives you and lists do not. Then check whether the licensing works for your audience. A design that is technically right and commercially impossible is not right.

How do I forecast capacity?

Estimate rows per year for the largest tables, decide where documents will live, and decide what is audited. Those three inputs produce a usable forecast; without them, any number is a guess.

What to take away

Two decisions — where documents live, and what is audited — account for most capacity surprises, and both are cheap to make correctly at the start and expensive to change later. The prices will move; those two decisions will still be the ones that mattered.