An honest technical guide to choosing between Microsoft Dataverse and SharePoint Lists as the data layer for your Power Platform project, covering when each is appropriate, performance, security, and cost.
Choosing between Dataverse and SharePoint Lists is the most consequential architectural decision in most Power Platform projects, and it is made incorrectly surprisingly often. SharePoint Lists are free, familiar, and quick to start with; Dataverse requires additional licensing but provides capabilities that matter for anything beyond simple applications.
The Quick Answer
Use SharePoint Lists when:
- The data is simple (under 5,000 rows per list)
- Access control is team or site-level (not row-level)
- Users already interact with the data in SharePoint
- The solution is a low-stakes internal tool
- Budget prevents Dataverse licensing
Use Dataverse when:
- You need row-level security (user sees only their records)
- The data has complex relationships between tables
- You need an audit trail of every change
- The app will have 10+ concurrent users
- The solution handles regulated or sensitive data
SharePoint Lists: The Real Limitations
SharePoint Lists work well for simple Power Apps, but they have hard limits that matter in production:
- 5,000 item view threshold: SharePoint limits list views to 5,000 items. For apps searching or filtering more than this, queries fail or return incomplete results. This is not a soft limit; it is a SharePoint architecture constraint.
- No row-level security: SharePoint permissions operate at list or item level, not at the row level based on data values. You cannot automatically show each user only their own records without custom filtering logic (which breaks at scale).
- No referential integrity: SharePoint has lookup columns but no enforced foreign key relationships. Related data can be orphaned and there is no cascade delete.
- Limited audit trail: SharePoint's version history captures document changes but is not designed for structured data audit trails with before/after values and user attribution required by regulatory frameworks.
- Delegation issues in Power Apps: Many Power Apps functions (Filter, Search, Sort) are not fully delegable to SharePoint, meaning they execute client-side on a limited data sample rather than server-side on the full dataset.
Dataverse: When the Cost Is Worth It
Dataverse requires Power Apps per-app or per-user premium licences (approximately £3.70/app/user/month or £16.90/user/month). For the right use cases, it provides capabilities that simply cannot be replicated on SharePoint:
- Row-level security via security roles: each user sees exactly the records they should, based on team membership, business unit, or record ownership
- True relational data model: parent/child relationships with referential integrity, cascade behaviours, and proper foreign keys
- Built-in audit log: every create, update, and delete is logged with user, timestamp, and field-level before/after values. Essential for regulated data
- Performance at scale: Dataverse is a purpose-built database; it handles millions of records and complex queries efficiently where SharePoint Lists struggle above 5,000
- Business rules and calculated columns: server-side validation logic that enforces data quality regardless of how records are created or modified
- Full delegability in Power Apps: Filter, Search, LookUp, and Sort are all delegated server-side against Dataverse
UK Licensing Cost Comparison
| Approach | Cost for 50 Users | Notes |
|---|---|---|
| SharePoint Lists | £0 (included in M365) | Within existing M365 licence; no incremental cost |
| Dataverse (Per App) | ~£2,220/yr | £3.70/app/user/month × 50 users × 12 months |
| Dataverse (Per User) | ~£10,140/yr | £16.90/user/month × 50 users × 12 months, unlimited apps |
Our Recommendation: Start with SharePoint Lists for simple, low-stakes internal tools where the 5,000-item limit will not be hit. Plan for Dataverse from the outset for any solution that needs row-level security, an audit trail, regulatory compliance, or will grow beyond a few hundred records per table. Migrating from SharePoint to Dataverse after the fact is painful, the architecture decision is much harder to reverse than the cost decision.
