Dataverse or SharePoint Lists: Choosing on Capability

Dataverse gets introduced as "the database behind Power Apps", which is accurate and unhelpful. SharePoint lists are also a database behind Power Apps. So is SQL Server. The description does not tell you when to reach for it.

The useful framing is different. Dataverse is not primarily storage. It is a set of behaviours — relationships, security, validation, business logic — that apply no matter what is reading or writing the data.

What Dataverse provides that a list does not

Relationships the platform understands

In a SharePoint list you can add a lookup column, and it is a reference. Dataverse relationships are real: they carry referential integrity, defined cascade behaviour, and navigation properties.

Practically, that means you can define what happens when a parent record is deleted — cascade, restrict, or orphan — and the platform enforces it everywhere. In a list, that logic lives in whatever app happens to be writing.

A security model with actual granularity

SharePoint permissions work on items, lists and sites. That is adequate for documents and awkward for business records.

Dataverse expresses security in terms the business already uses: security roles, business units, and record ownership. "A salesperson sees their own accounts; a manager sees their team's; a director sees the region" is a configuration, not a set of item-level permissions somebody has to maintain.

This is often the deciding factor. Row-level security that follows an organisational hierarchy is genuinely difficult to reproduce with list permissions, and painful to maintain once built.

Logic that lives with the data

Validation implemented in a canvas app protects that app. Anything else writing to the same list — a flow, a script, a second app, a bulk import — bypasses it.

Dataverse business rules, calculated columns and plug-ins run at the data layer. Every path in gets the same enforcement. For anything with real integrity requirements, this is the difference between a rule and a suggestion.

Typed columns

Dataverse has genuine types: currency with precision, choice sets defined once and reused, decimals with defined scale, durations. SharePoint's type system is looser, and the gaps surface as rounding errors and inconsistent option values.

When a SharePoint list is the right answer

Reaching for Dataverse by default is as much a mistake as avoiding it. Lists are the better choice when:

• The data is genuinely document-centric — the file matters more than the record
• The volume is modest and will stay that way
• Permissions are simple, at site or list level
• Business users need to work directly in the data, in a familiar grid
• Licensing constraints rule out premium connectors
• The application is a form and a view, not a system

A departmental request tracker used by fifteen people does not need Dataverse. Choosing it there adds licensing cost and administrative overhead for capability nobody will use.

Choosing between them

If you need…	Choose
Row-level security following an org hierarchy	Dataverse
Referential integrity across related records	Dataverse
Validation enforced regardless of the client	Dataverse
Model-driven apps	Dataverse
Broad delegation on large datasets	Dataverse
Documents with metadata	SharePoint
A simple tracker for a small team	SharePoint
To stay within standard licensing	SharePoint
Users editing directly in a grid	SharePoint

Licensing, honestly

Dataverse requires premium licensing. SharePoint lists are available with a standard Microsoft 365 licence.

Licensing terms and prices change, so treat specific figures as something to confirm rather than something to read in an article. What does not change is the shape of the decision: Dataverse has a per-user cost that SharePoint does not, and that cost must be justified by capability you will actually use.

The honest test: if you cannot name a specific Dataverse capability your application needs — security roles, cascading deletes, server-side business rules, model-driven apps — then you are paying for something you are not using.

Common mistakes and better practice

• Choosing Dataverse because it sounds more professional. A small tracker on Dataverse is a small tracker with a licensing bill.
• Choosing SharePoint for transactional data that will grow. Delegation limits and the view threshold become real constraints. If the data will get large, decide early.
• Rebuilding relational structure in lists. Multiple lists joined by lookups, with integrity maintained by flows, is a relational database implemented badly. That is the signal to move.
• Migrating late. Moving from lists to Dataverse means rebuilding apps, flows and permissions. It is far cheaper to decide correctly at the start.
• Enforcing validation only in the app. If a flow or an import can bypass your rules, they are not rules.
• Treating environments as an afterthought. Dataverse lives in an environment with its own lifecycle. Plan development, test and production separately.

Troubleshooting and common friction

Situation	Cause	What to do
Users cannot see records they should	Security role or business unit scope	Review the role's read privilege depth against the ownership model
Delete blocked with a relationship error	Cascade behaviour set to restrict	Remove child records first, or reconsider the cascade setting
Business rule not firing for a flow	Rule scoped to a specific form rather than the table	Set the scope to the entity so it applies server-side
Choice values inconsistent across apps	Local choice column instead of a global choice set	Define a global choice and reuse it
Solution import fails between environments	Missing dependency or component version mismatch	Read the import log; add the missing component to the solution

Frequently asked questions

Is Dataverse just SQL Server with a different name?

No. It is a data platform including security, relationships, business logic, auditing and an API surface. Storage is one part of it.

Can Dataverse and SharePoint be used together?

Yes, and it is a common pattern: structured records in Dataverse, supporting documents in SharePoint, related through the platform's document management integration.

Is migrating from lists to Dataverse straightforward?

The data moves readily. The apps, flows, and permission model are the work. Decide early rather than migrating later.

Does Dataverse remove the delegation problem?

It substantially reduces it. Dataverse supports the widest range of delegable operations, but delegation still applies and formulas still need checking.

What is the clearest signal to move?

Multiple related lists whose integrity is maintained by flows, or permission requirements that item-level permissions cannot express cleanly. Both mean you have outgrown lists.

Deciding on capability, not on size

The choice is not about how much data you have. It is about what the data has to guarantee.

If the answer involves relationships the platform must enforce, security that follows an organisational structure, or validation that holds regardless of how the data is written, Dataverse earns its cost. If it does not, a well-designed SharePoint list will serve the same users for less, and be easier for them to work with.