In Short: The Cheap Default and the Real Database
Under every Power App and many a flow sits a quiet decision: SharePoint list or Dataverse? The list is the cheap, familiar default - included in licensing, made in minutes, fine for genuinely light tracking. Dataverse is the platform's actual database: relational, secured, audited, built to carry business processes. Most Power Platform pain we get called into traces to this fork taken casually - a process that was really a system, built on storage that was really a list.
Here is each option honestly, and the rule that prevents the rebuild.
What Lists Are Actually For
SharePoint lists shine as team-level tracking: the register, the simple checklist, the lightweight intake queue. Their virtues are real - zero marginal licence cost, instant creation, natural SharePoint integration, and familiarity that makes adoption frictionless.
Their limits are equally real and arrive on schedule as usage grows: the view threshold that makes large lists demand careful indexing and view discipline; lookups without integrity (relational pretence, not relational behaviour); item-level permissions that degrade into an unmanageable, slow patchwork; and delegation limits that make apps over big lists quietly compute on partial data - the classic source of "the app shows different totals than the export".
None of that is a design flaw; lists were never meant to be a database. The flaw is ours, when a compliance-relevant process ends up on one.
What Dataverse Actually Buys
- Relational integrity: real tables, real relationships, constraints that hold
- Server-side logic: business rules and validation that apply regardless of which app or flow touches the data
- Security that scales: role-based access to tables, rows and columns - the governance-grade model processes deserve
- Audit and history: who changed what, when - answerable, not archaeological
- A clean analytics path: Dataverse flows naturally into OneLake and Power BI, so operational data becomes analytical data without export rituals
The cost is licensing: apps on Dataverse generally need premium licences. The honest comparison is not licence-versus-free; it is licence-versus-consequences - the rebuild, the audit finding, the delegation bug in month nine.
The Decision Rule That Prevents Rebuilds
Choose lists when all of these hold: single team, simple flat data, no meaningful security segmentation, no money or compliance in the loop, and modest volumes. Choose Dataverse when any of these hold: relationships that must hold, role-based access, audit expectations, cross-team processes, integration duties, or the phrase "business-critical" appearing anywhere near the app.
And prototype freely, but graduate deliberately: the moment a list-backed prototype earns production status, budget the move rather than discovering it during an incident. In our backlog-clearing engagements, the apps that stayed cheap were the ones whose data home was chosen on purpose, on day one.
Sources and Further Reading
Frequently asked
A list is lightweight tracking storage inside SharePoint: columns on items, easy sharing, included in Microsoft 365 licensing. Dataverse is the Power Platform's actual database: relational tables, server-side rules, role-based security, auditing and proper API behaviour - built to carry business applications.
Licensing and familiarity: lists are included where Dataverse use in apps typically needs premium licensing, and everyone has made a list. It is a rational default for genuinely light cases and an expensive one when the process underneath is actually relational, secured or business-critical.
The classics: the list view threshold (large lists need careful indexing and views to stay usable), weak relational integrity (lookups without real constraints), item-level security that gets slow and unmanageable, and delegation limits that quietly return wrong subsets to apps. None are showstoppers for small; all are for serious.
Real database behaviour: relationships with integrity, business rules that run server-side, security roles down to column level, auditing, and clean integration into analytics (Dataverse data flows to OneLake and Power BI naturally). For process-critical apps the licence usually costs less than the rebuild it prevents.
Technically yes, and it is a real project: schema redesign, data migration, app rework, retraining. The pragmatic rule: prototype on whatever is fastest, but any process involving money, compliance or multiple teams should start on Dataverse rather than plan a migration it will resent.
