Dataverse vs SharePoint Lists: Where Should Your Power Apps Data Live?
SharePoint lists come with Microsoft 365 and handle a simple tracker well. Dataverse needs premium licensing and earns it once the data turns relational, sensitive, or large. Here is where the line sits, using the limits from Microsoft's own documentation.
By Shuvam, Founder of KodeBiz · Updated 5 Oct 2026
Dataverse vs SharePoint list: the short answer
In the Dataverse vs SharePoint list decision, start on a SharePoint list when the app is a simple tracker for one team: flat data, a few thousand rows, access that follows the site, and users on Microsoft 365 licences. Move to Dataverse when records have parents and children, when access depends on role, branch or a single sensitive column, when rules must hold however a record is edited, or when lists will grow past what Power Apps can query correctly.
It is rarely all or nothing. Documents usually belong in a SharePoint library whichever store holds the records. In the law-firm ERP we built for King Stubb & Kasiva, matter intake and conflict checks run on Dataverse-backed schemas, while each matter's files sit in a SharePoint library mapped one-to-one to the matter, with version history on.
Five questions settle most cases:
- Volume: will any list pass 5,000 items?
- Shape: are there parent-child records, like orders and order lines?
- Access: does visibility depend on role, branch, or one sensitive column?
- Rules: must validation hold outside the app?
- Licences: Microsoft 365 only, or premium Power Apps licences?
SharePoint list limitations: the 5,000-item threshold and delegation
A SharePoint list can hold up to 30 million items, so size is rarely the issue. The constraint is the list view threshold: 5,000 items is the most a single database operation, such as a query, can process at one time, and in SharePoint in Microsoft 365 it can't be changed. Indexing the columns you filter on (a list takes up to 20 indexes) and keeping views filtered is how large lists stay usable.
Power Apps adds a second limit: delegation. When a formula translates into a query the data source understands, the source does the filtering. When it doesn't, Power Apps fetches only the first 500 records and filters those on the device. You can raise that to 2,000 in Settings under Data row limit, but no higher. Users get no error, just incomplete results; the only signal is a delegation warning in the editor.
Delegation is also where the two platforms split:
- SharePoint: Filter, LookUp, Sort and StartsWith delegate; Search and the In operator are not on its delegable list, Not won't delegate, and the ID column only delegates an equals test
- Dataverse: Search on text columns, In, CountRows, Sum, Min, Max and Average also delegate (aggregates up to 50,000 rows)
- Microsoft's own testing tip: set the data row limit to 1, so any formula that doesn't delegate shows itself immediately
Dataverse vs SharePoint on relationships, rules and security
SharePoint links lists with lookup columns. Lookups work within one site, can optionally restrict or cascade deletes, and a view has a default threshold of twelve lookup columns. That is fine for a customer lookup, but strained once customers, orders, order lines, products and GST rates all link up.
Dataverse treats relationships as metadata: one-to-many and many-to-many, each with behaviours for delete, assign, share and reparent. Restrict blocks deleting a customer while orders still point at it; cascade passes a reassignment down to the related records.
For rules, a SharePoint list offers column and list validation formulas, and anything heavier runs in a Power Automate flow after the item is saved. Dataverse business rules can set values, set defaults and validate data; defined at table scope they apply at the server level and in canvas apps that use the table. Real-time workflows and plug-ins handle the rest.
Security is the sharpest difference. SharePoint grants permissions on sites, lists, folders and individual items, and a list can limit people to reading or editing only the items they created. Unique item permissions are supported up to 50,000 per list, with 5,000 recommended. Dataverse combines security roles with business units: each privilege, such as create, read, write, delete, assign or share, gets an access level from the user's own records up to the whole organisation. Column-level security then hides a single column, such as margin or salary, from people who can see the rest of the row.
Auditing, licensing and capacity
Dataverse auditing records who created or updated a record, which columns changed, the previous value, and who deleted it. It is switched on per environment, table and column, and the Audit Summary view lists every audited change. A SharePoint list can keep a version on every edit. That suits a tracker, but the history sits on each item, not in one audit view.
Licensing usually decides it. The SharePoint connector is a standard connector, and some Microsoft 365 licences include Power Apps use rights for Microsoft 365 data and standard connectors. Dataverse tables, premium connectors and on-premises gateways need premium entitlements, such as Power Apps Premium, and model-driven apps are premium by default. Microsoft has announced stricter enforcement of those requirements from February 2027.
Dataverse for Teams sits in between. It comes with select Microsoft 365 subscriptions and gives each team one 2 GB environment, roughly a million rows. On Office-seeded licences its apps run only inside Teams, and it has one business unit, no auditing, no column-level security and no API access.
Storage is pooled differently too. SharePoint gives a tenant 1 TB plus 10 GB per licence on business and enterprise plans. Dataverse splits capacity into database, file and log, built from a tenant default plus per-licence accruals; attachments use file capacity and audit logs use log capacity. Run short and environment operations such as copying or restoring can be blocked.
Dataverse vs Excel and Dataverse vs SQL Server
An Excel workbook in OneDrive is the weakest backend of all. Microsoft's performance guidance says Excel isn't a relational database and that the Excel connector limits a canvas app to loading 2,000 records from a table. The connector documentation adds: a file can stay locked for up to six minutes after the connector last used it, simultaneous edits from Excel, flows and apps aren't supported and can cause merge conflicts, files are capped at 25 MB, and writes can take up to 30 seconds to appear.
Treat the workbook as a migration source instead. Power Apps can upload an Excel or CSV file straight into a new Dataverse table.
SQL Server or Azure SQL is a fair choice when a team already runs SQL. The connector delegates well and supports views and stored procedures. It is a premium connector in Power Apps and Power Automate, so the licensing question matches Dataverse, and an on-premises server is reached through the on-premises data gateway. What you give up is the Dataverse layer: security roles, audit views, business rules and model-driven apps. On SQL, the equivalents are work your team builds and maintains.
The decision table, and moving later without a rewrite
The last line below matters most if you start small. A later move to Dataverse is ordinary migration work when the lists were designed relationally from day one: most screens and formulas carry over, Person and Choice columns usually need rework, and Power Query dataflows move the data.
- Start on SharePoint lists when one team uses the app, lists stay in the low thousands, data is flat, access follows the site or 'own items only', and users have Microsoft 365 licences only
- Go to Dataverse when records have parents and children, lists will pass 5,000 items, access depends on role, branch or a sensitive column, rules must hold outside the app, or auditors will ask who changed what
- Consider Dataverse for Teams when the app lives inside one team, stays under 2 GB, and needs neither auditing nor column security
- Use SQL Server or Azure SQL when the data already lives there and someone owns that database
- Keep Excel as an import source, never a live backend for more than one person
- To migrate later without a rewrite: one list per entity joined by lookups, your own reference number on every row instead of the SharePoint ID, controlled values for status, and business rules kept in one place
How we approach it at KodeBiz
We choose the data store during the requirement study, not after the first screen. Sitting with the team, we count the rows in each register and how fast they grow, list who must see what down to the column, note the rules that must hold even when a record is edited outside the app, and check which licences people already hold. The written scope names the store, the reason, and the licence and capacity implications.
If the answer is Dataverse, design starts with the schema: tables, relationships, business rules and security roles, with a model diagram finance can read. If it is SharePoint, the lists are still designed relationally. Testing uses production-sized data with the row limit set low, so a formula that doesn't delegate fails in testing rather than in daily use. Data moves in rehearsed passes (sample, validation, rehearsal, go-live), the team is trained on its own workflows, and support afterwards includes watching list growth and Dataverse capacity. Timelines are agreed once the requirement study is complete.
SharePoint lists suit flat, single-team trackers on Microsoft 365 licences; Dataverse earns its premium licensing once data is relational, access is role- or column-based, rules must hold server-side, or lists outgrow delegation. Design the lists relationally from day one, and the move to Dataverse stays a migration, not a rebuild.
Frequently asked
Can Power Apps handle a SharePoint list with more than 5,000 items?
Yes, provided the queries delegate. A list can hold 30 million items, but the 5,000-item list view threshold can't be changed in Microsoft 365, and a formula that doesn't delegate sees only the first 500 records (2,000 at most). Index the columns you filter on, use delegable functions like Filter, LookUp and StartsWith, and treat every delegation warning as a bug.
Do I need a premium licence to use Dataverse with Power Apps?
For full Dataverse, yes. Microsoft lists Dataverse tables, premium connectors, custom APIs and on-premises gateways as premium features, and model-driven apps are premium by default. Microsoft 365 licences cover apps on Microsoft 365 data and standard connectors, including SharePoint lists. The exception is Dataverse for Teams: it comes with select Microsoft 365 subscriptions, but those users can run its apps only inside Teams.
Is Dataverse for Teams enough for a small business app?
For an app that lives inside one team, often yes. Each team gets one 2 GB environment, roughly a million rows. It has one business unit and no auditing, column-level security, API access or model-driven apps. An admin can upgrade it to full Dataverse, after which users need Power Apps licences and its storage counts against the tenant's Dataverse capacity.
How do I migrate a Power Apps app from SharePoint lists to Dataverse?
Recreate the lists as Dataverse tables with proper relationships, load the data with Power Query dataflows, then repoint the app and fix formulas that relied on SharePoint-specific column types. It goes smoothly when the lists were designed relationally, with one list per entity and your own reference numbers as keys. Rehearse on a copy, reconcile counts, then cut over.