SharePoint lists vs Dataverse for internal tools
Last updated:
Start with lists. They are included in Microsoft 365, everyone in the organisation already knows how to open one, they carry SharePoint's permission model, they export to Excel, and they are readable by every tool in the stack. For the overwhelming majority of internal tools — trackers, registers, request logs, directories, inventories — that is the correct and complete answer.
Dataverse is a real database, with relational integrity, row-level security, proper data types, business rules and auditing. It is the right answer when your data has genuinely outgrown a list, and the wrong one when it has not — because it brings per-user licensing, a different skill set, and an administrative surface somebody has to own.
The mistake worth avoiding is choosing Dataverse on the strength of a hypothetical future. Migrating a list to Dataverse later is a known, bounded task. Paying per user for two years for a register of forty rows is not recoverable.
The honest comparison
| SharePoint lists | Dataverse | |
|---|---|---|
| Cost | Included with Microsoft 365 | Per-user licence, plus capacity |
| Who can create one | Anyone with a site | Someone with an environment and rights |
| Relationships | Lookup columns, no referential integrity | Real relationships, enforced |
| Security | SharePoint permissions, item level possible but awkward | Row and field level, designed for it |
| Comfortable size | Thousands to low tens of thousands of items | Millions |
| Users can see the raw data | Yes, it is just a list | No, it needs an app or a maker tool |
| Exit | Export to Excel, or leave it where it is | Export, and rebuild whatever consumed it |
The sixth row cuts both ways and deserves a deliberate decision. A list being directly openable is a feature for adoption — people trust what they can see, and they can fix a typo themselves. It is a drawback when the data should not be casually browsable, which is one of the genuine arguments for Dataverse.
The four signals you have outgrown lists
- You need enforced relationships. Deleting a customer must not leave orphaned orders, and a lookup column will not stop it. This is the strongest single argument.
- You need row-level security that SharePoint cannot express. Sales reps must see only their own accounts, within one dataset. Item-level permissions technically exist in SharePoint and become unmanageable at scale.
- You are past the list view threshold and it hurts. Lists hold millions of items but views throttle at 5,000, and once your filters and indexes are fighting that limit daily, you are working around the platform rather than with it.
- You need auditing and business rules in the data layer, not in whatever application happens to write to it.
If none of those four is true, you have not outgrown lists — you may just have an unindexed column or a view that returns everything. That is a much cheaper problem.
The list limits that actually bite
Worth knowing so you can recognise them rather than mistaking them for a reason to migrate:
- The 5,000-item view threshold. The list can hold far more; a single view cannot return more than 5,000 items at once. Usually solved with indexed columns and filtered views, not with a new platform.
- Lookup columns are not joins. They display a value; they do not enforce anything, and complex lookups get slow.
- Item-level permissions do not scale. They work, and they become an administrative burden well before they become a technical one.
- No transactions. If two related writes must both succeed or both fail, a list will not guarantee it.
Notice that only the last two are truly architectural. The first is a configuration problem people routinely misdiagnose as a scale problem — and it is the single most common reason someone concludes, incorrectly, that they need to leave SharePoint.
Frequently asked questions
Is Dataverse included with Microsoft 365?
Not for general use. There is a limited Dataverse for Teams available within Teams, with reduced capabilities and its own boundaries, but full Dataverse requires Power Apps or Dynamics 365 licensing, charged per user. That licensing question should be settled at the start of a project, not after a successful pilot.
Can we start with lists and move to Dataverse later?
Yes, and it is usually the right sequence. Moving the data is the easy part; the work is rebuilding whatever read from it. Keep that cost low by not scattering direct list references across many custom components — a platform that reads lists through configuration makes the eventual repoint much cheaper than hard-coded queries in bespoke code.
We have 50,000 items in a list. Is that a problem?
Not by itself — lists handle far more. What you need is indexed columns and views that filter to under 5,000 returned items. If your views are configured well, 50,000 items is unremarkable. If every view tries to return everything, you will feel it at a few thousand and blame the wrong thing.
What about SQL Server or an external database?
A valid option when the data belongs to another system, or is already there. Be aware of the licensing consequence in the Power Platform: reaching SQL Server from Power Apps or Power Automate uses a premium connector, which is per user per month for everyone who touches it. That is often a bigger number than the database.