If you’re building a Power App and you’ve gotten to the point of choosing where your data lives, you’re facing one of the most consequential decisions in the whole project. Get it right and everything downstream is easier. Get it wrong and you’re refactoring six months later.
The good news is that this isn’t really a close call for most use cases — once you understand what each platform is actually built for, the right answer usually becomes obvious.
What SharePoint Lists Are Good For
SharePoint Lists have been around for a long time, they’re included with every Microsoft 365 business subscription, and they work well as a Power Apps data source within a specific range of scenarios.
Use SharePoint Lists when:
You have a simple, flat data structure. A task list, a contact directory, an event log, a document tracker — anything that lives comfortably in a single table without complex relationships between records. SharePoint Lists handle these well.
Your user count is modest. SharePoint Lists are not built for high-concurrency environments. If you have a handful of people using the app intermittently, you’ll be fine. If you have dozens of users hitting the list simultaneously, you’ll start running into throttling, delegation limits, and performance problems.
You need tight SharePoint integration. If your app is fundamentally tied to a SharePoint document library — approvals, metadata tagging, document routing — keeping your data in SharePoint Lists makes the integration cleaner and the permissions model simpler.
Budget is a real constraint. SharePoint Lists cost nothing beyond your existing M365 license. If you’re building something internal, lightweight, and low-stakes, there’s no reason to introduce a Dataverse license cost if SharePoint gets the job done.
You need something running quickly. SharePoint Lists are fast to set up. If you’re building a proof of concept, an MVP, or something that needs to be live in a week, starting on SharePoint is often the pragmatic call — with the understanding that you may migrate later.
What Dataverse Is Built For
Dataverse is a proper relational database platform. It was designed to be the backbone of serious Power Platform applications, and it shows. The feature set is meaningfully different from SharePoint in ways that matter as soon as your requirements get real.
Use Dataverse when:
You have related data across multiple tables. If your app tracks customers, and each customer has jobs, and each job has line items, and each line item connects to an inventory record — that’s a relational data model. SharePoint Lists can’t handle that cleanly. Dataverse was built for exactly that structure.
You need real security and access control. Dataverse has row-level security, column-level security, and a full role-based access control system. You can control who sees which records, who can edit what fields, and who has no business seeing certain data at all. SharePoint permissions are comparatively blunt.
You’re building something people depend on daily. If the app is going to run a real business process — job tracking, client management, field operations, compliance workflows — you want a platform that can handle concurrent users, enforce data integrity, and give you audit history. Dataverse delivers all of that. SharePoint Lists do not.
You need delegation to actually work. One of the most frustrating limitations of SharePoint as a Power Apps data source is delegation. Power Apps can only process the first 500 to 2,000 records client-side by default, and many filter and sort operations can’t be delegated to SharePoint at all. With larger datasets, this creates real problems. Dataverse handles delegation properly and supports datasets of virtually any size.
You’re integrating with the broader Power Platform. Power Automate, Power BI, and Dynamics 365 all work more naturally and more powerfully with Dataverse than with SharePoint. If your roadmap includes automation, dashboards, or CRM functionality, Dataverse is the right foundation.
You need audit history. Dataverse has built-in audit logging. You can see who changed what record, when, and what it looked like before. SharePoint Lists have version history on individual items but nothing close to the audit capability Dataverse provides.
The Honest Trade-off
The main thing SharePoint has going for it over Dataverse is cost and simplicity. Dataverse requires a Power Apps per-user or per-app license beyond standard Microsoft 365. For internal business applications with a defined user group, that cost is usually justifiable — but it’s a real consideration for small teams watching the budget.
SharePoint is also genuinely easier to set up and manage for non-technical owners. You can build and modify a SharePoint List without touching anything that feels like database administration. Dataverse has more moving parts: environments, solutions, security roles, and a data model that rewards planning upfront.
The mistake we see most often is starting on SharePoint because it’s free and easy, building something that becomes business-critical, and then discovering six months in that the delegation limits, the performance issues, or the inability to model related data properly means the whole thing needs to be rebuilt on Dataverse. That rebuild costs more than starting on Dataverse would have.
A Simple Decision Framework
If you’re not sure which to choose, run through these questions:
Do you have more than one related table of data? → Dataverse.
Will more than 10–15 people use the app regularly or simultaneously? → Dataverse.
Do you need row-level security — different users seeing different records? → Dataverse.
Is your dataset likely to exceed 2,000 rows in the next year? → Dataverse.
Is this a simple single-table list and budget is tight? → SharePoint Lists are fine.
Are you building a quick internal tool or proof of concept? → Start with SharePoint, plan to migrate.
What We Typically Recommend
At AccessEvolved, we default to Dataverse for anything that’s going to run a real business process. The licensing cost is modest relative to the value of having a proper data platform underneath your application, and the headaches you avoid — delegation issues, concurrency problems, permission limitations — are worth it.
SharePoint Lists are a legitimate choice for simple, low-stakes internal tools. We use them when the use case fits. But when a client comes to us with a serious operational need, we’re not going to build it on a foundation that’s going to crack under load.
If you’re in the planning stages of a Power Apps project and you’re not sure which direction makes sense for your specific situation, that’s exactly the kind of question we help answer.
Ready to talk through your options? Reach out to Anthony at AccessEvolved — email anthony@accessevolved.com or call 212-951-1010. No sales pitch, just a straight conversation about what makes sense for your situation.