Dataverse vs SharePoint: when each is the right backend

“Should this be a SharePoint list or a Dataverse table?” is one of the most consequential questions in a Power Platform build, and one of the most commonly rushed. Pick SharePoint because it’s already there, and you can spend the next year fighting delegation limits and security you can’t express. Pick Dataverse for a five-item lookup list, and you’ve added licensing and complexity you didn’t need.

Here’s how I decide.

The problem: the default choice is usually the wrong one

SharePoint lists are the path of least resistance. They’re included, familiar, and quick to spin up, so they become the default backend for apps that quietly grow into something a list was never meant to hold. The pain shows up later: the 5,000-item view threshold, delegation warnings that silently return partial data, and permission models that can’t represent “these people can edit their own records but only read everyone else’s.”

By the time it hurts, the app is in production and the data is entangled with it.

The solution: match the backend to the shape of the data

The decision comes down to a few honest questions about the data, not the convenience of the tooling.

Reach for Dataverse when:

• The data has relationships that matter: records that reference other records, rolled-up totals, cascading behaviour.
• You need row-level security or role-based access more nuanced than a SharePoint permission can express.
• The data will be large or high-volume, or queried in ways that will hit delegation limits.
• Multiple apps, flows, or reports will share the same data and need one consistent model.
• Auditing, business rules, or server-side logic are part of the requirement.

SharePoint is genuinely fine when:

• The data is a flat, modest list: reference data, simple task tracking, a small lookup.
• Document storage is the actual point, and metadata is secondary.
• The audience and permissions are simple, and the list won’t grow without bound.

The technical detail that decides it

The two that catch teams out most often are delegation and security. Delegation determines whether a query runs on the server or pulls a capped set of rows to the client, and SharePoint’s delegation support is narrower than Dataverse’s, so complex filters on large lists quietly return incomplete data. Security is the other: Dataverse’s role and row-level model can express ownership and sharing rules that SharePoint simply can’t, and retrofitting that later usually means a migration.

If either of those is in your future, decide for Dataverse now. Migrating a live app off SharePoint is far more expensive than choosing correctly on day one.

The outcome

Choosing the backend deliberately (before the first screen) is one of the cheapest, highest-leverage decisions in a Power Platform project. Get it right and the app stays fast, secure, and extensible. Get it wrong and you pay for it in delegation workarounds, permission hacks, and eventually a migration you scheduled far too late.

When in doubt, ask what the data will become, not what’s easiest today.