Dataverse vs. SQL vs. SharePoint: A Guide

"Should we build this in Dataverse, in SQL, or just in SharePoint Lists?" — this question stands at the start of almost every mid-market Power Platform project, and it's often answered from the gut: SharePoint, because it's already there. SQL, because IT knows it. Dataverse, because Microsoft recommends it. All three rationales are worthless.

This post compares the three honestly — with costs, limits, and what happens after two years, not just on demo day. The goal isn't to sell you Dataverse, but to spare you the expensive wrong decision.

1. What We're Actually Deciding Here

The three aren't opponents on the same level — they solve different problems:

SharePoint Lists — a list tool for teams. Included in every M365 license, never intended as an application database.
Azure SQL — a pure database engine. Maximum control, but you build logic, security, and the interface on top yourself.
Dataverse — in between: relational data storage plus logic plus a security model, integrated into the Power Platform out of the box.

The right question isn't "which is best," but "which fits the lifecycle the application has ahead of it." Most wrong decisions happen because the application looks like SharePoint in the demo and is a SQL problem in two years.

2. The Honest Comparison

The following diagram sums up the axes along which the decision is made — not feature lists, but suitability over time.

SharePoint Lists — Quick to Start, Hard Ceiling

SharePoint Lists is good for what it was made for: a manageable list that a team maintains together. Instantly there, costs nothing extra, Power Apps accesses it directly.

The ceiling arrives sooner than expected. The 5,000-item threshold isn't a hard data limit, but from there on filtering, sorting, and delegable queries become constant friction. Relationships between lists are fragile — there's no referential integrity. Permissions are coarse; you won't build a clean, row-level, role-based model with it.

Honest recommendation: right when the application stays small, is team-internal, and needs no hard permissions. As soon as "open it up for department X later" or "make it interplay with the CRM" comes up, it's the wrong foundation — the rebuild is more expensive than the correct start.

Azure SQL — Maximum Control, Maximum In-House Effort

Your own SQL database gives you everything: full control over schema, indexes, optimization, any load. For high-frequency, write-intensive scenarios with millions of transactions, often the only sensible choice.

The price sits elsewhere: you build security, logic, the API, the interface, and the lifecycle yourself. What Dataverse brings along — a role model, audit, Web API, Power Apps integration — is custom development with SQL. Not an argument against SQL, but a cost truth: cheap on the license, expensive in in-house effort over its lifetime.

Honest recommendation: right with very high load, custom development outside the Power Platform context, or a genuine need for engine control. For the typical mid-market business app, usually over-engineering.

Dataverse — the Middle Path with the Lowest Follow-Up Costs

Dataverse is rarely the cheapest on decision day and often the most economical over its lifetime: relational data storage, a row-level security model, logic at the record, and integration into Power Apps, Power Automate, and Power BI — without building any of that yourself.

The trade-off: license costs per user or per app and a learning curve on the data and security model. Whoever treats Dataverse like a SharePoint list pays the platform price without the benefit. How to do it right: the Dataverse guide.

3. The Decision Logic as a Chain of Questions

Instead of a feature table: four questions that almost always suffice.

This chain doesn't replace architecture consulting, but it filters out the wrong options quickly. The most common mistake: starting an application with a long lifecycle on SharePoint because it's the fastest on demo day.

4. The Hidden Costs Nobody Writes Into the Demo

Every option has costs that only become visible after months:

SharePoint: the remediation effort when the application outgrows the list limit or coarse permissions. A migration to Dataverse is doable, but never trivial.
Azure SQL: the ongoing in-house effort for everything Dataverse brings along — security, API, interfaces, lifecycle. A permanent line item.
Dataverse: license costs with many occasional users, and the learning curve. Whoever sets up the data and security model sloppily additionally pays the remediation effort — see Security Roles and data modeling best practices.

The sober view: never calculate just the license price, but the total cost of ownership over three to five years, including likely growth. That way Dataverse wins more often for the typical mid-market business app than the day rate suggests — and SharePoint less often than its zero license cost implies. Overall context: The Microsoft Power Platform Guide for the Mid-Market.

Conclusion

There's no universally best option, but predictably wrong ones. SharePoint Lists is right as long as the application stays small and team-internal, and becomes a mortgage when it grows. Azure SQL is right with high load and a need for control, over-engineering for the typical business app. Dataverse is rarely the cheapest on decision day and often the most economical over its lifetime — provided you treat it as a platform, not as a better list.

The most honest recommendation: don't decide by what the application is today, but by what it foreseeably becomes in two years. This shift in perspective prevents most expensive wrong decisions.

Unsure What Fits Your Case?

We'll look at your use case — lifecycle, user count, permission needs — and tell you honestly which of the three options holds up. Even if the answer is "SharePoint is enough."

Talk through your use case See our Power Platform services