Power Apps Dataverse vs SharePoint List: Which One Should You Use?

If you’ve spent any time building apps in Power Apps, you’ve almost certainly hit this exact question: Should I store my data in a SharePoint list or in Dataverse?

It’s one of those decisions that feels simple on the surface but can seriously affect how your app performs, scales, and behaves six months down the road. Pick the wrong one early, and you’re either rewriting everything or stuck with an app that crawls to a halt when your data grows.

I’ve worked with both, and in this tutorial, I’m going to walk you through the real differences — not just a boring feature comparison, but the practical stuff that actually matters when you’re building.

What Is a SharePoint List, Really?

A SharePoint list is essentially a table you can create inside a SharePoint site. Think of it like an Excel table that lives in the cloud. It has rows and columns, people can view and edit it directly in SharePoint, and you can connect to it from Power Apps without needing any extra licensing.

It’s been around for over 20 years, which tells you something — it’s reliable, familiar, and deeply woven into the Microsoft 365 world. Most people in your organization probably already know what SharePoint is. That’s a big deal when you’re trying to get adoption for a new app.

Here’s what a SharePoint list gives you out of the box:

• Columns for text, numbers, dates, choices, people, lookups, and more
• Built-in views and filtering directly in SharePoint
• Version history and basic item-level permissions
• Tight integration with Power Automate for simple workflows
• No extra licensing — it comes with almost every Microsoft 365 plan

What Is Dataverse?

Dataverse is Microsoft’s cloud-based relational database, and it’s the native data platform for the entire Power Platform. It’s built on top of Azure SQL, which means it behaves more like a proper database than a list.

When you use Dataverse, you’re working with tables (not lists), and those tables can have real relationships between them — one-to-many, many-to-many, the works. You can also build model-driven apps in Power Apps, which is something you simply can’t do with a SharePoint list.

Here’s what Dataverse brings to the table (pun intended):

• True relational data model with table relationships
• Row-level and column-level security (much more granular than SharePoint)
• Business rules and calculated columns built right into the data layer
• Full delegation support, so large datasets don’t break your app
• Audit logging and change history at the data level
• Supports both Canvas Apps and Model-Driven Apps
• Deep integration with Dynamics 365, Power BI, and AI Builder

The catch? You need a Power Apps Premium licence to use it in production. More on that in a moment.

The Big Differences That Actually Matter

Let me break down the areas where these two really diverge in practice.

The 5,000-Item Problem (Delegation)

This is the one that bites almost everyone who starts with SharePoint lists and then grows their app.

Power Apps has a concept called delegation. When your app filters or searches data, it ideally sends that query to the data source (server-side), and the data source returns only the matching records. That’s efficient.

But when you use a function or a column type that SharePoint doesn’t support in a delegated way, Power Apps has to download a chunk of records locally and then filter them on your device. And here’s the problem — it only pulls a maximum of 2,000 records by default (you can bump this to 2,000 in the settings, but not beyond).

So if your SharePoint list has 10,000 rows and you’re searching on a column that isn’t delegable, you’re only ever searching through the first 2,000. Your users will get wrong results and won’t even know it. That’s the kind of bug that’s really embarrassing to explain.

Dataverse handles delegation far better. Most filter and search operations are fully delegable, which means it can process millions of records server-side without ever hitting a local limit. If your data is going to grow, this alone is a massive reason to consider Dataverse.

Data Relationships

SharePoint lists don’t have real relationships. Yes, you can add a Lookup column that points to another list, but it’s very limited — you can only pull one column from the related list, and it doesn’t support cascading deletes, referential integrity, or anything resembling a proper foreign key.

Dataverse supports one-to-many and many-to-many relationships natively. You can look up related records across tables, enforce referential integrity, and use rollup and calculated columns that aggregate data from related tables automatically. If your app has anything more complex than a flat list — say, orders that have multiple line items, or employees that belong to departments — Dataverse gives you the tools to model that properly.

Security

This is where SharePoint’s approach starts to feel a little basic when compared to Dataverse.

SharePoint security works at the site level, list level, and item level. You can share a list with a group of people or lock down individual items, but the configuration gets complicated quickly, and there’s no easy way to say “this user can read all records, but only edit their own.”

Dataverse uses role-based access control (RBAC). You create security roles, assign them to users or teams, and define permissions at a very granular level — per table, per operation (create, read, update, delete), and even per column. You can hide an entire column from certain users without any custom code. For anything business-critical, this kind of control is invaluable.

Performance at Scale

SharePoint lists technically support up to 30 million items, but performance starts to degrade noticeably beyond around 100,000 records — especially in Power Apps. You’ll need to carefully manage indexed columns and view thresholds, and even then, some operations just get slow.

Dataverse is purpose-built for enterprise-scale workloads. It handles millions of rows without breaking a sweat, with optimised querying and no arbitrary thresholds to work around.

App Types You Can Build

Here’s something a lot of people miss. If you want to build a Model-Driven App in Power Apps, you must use Dataverse. SharePoint lists aren’t supported for model-driven apps at all.

Canvas Apps work with both. So if you’re happy building canvas apps (which are perfectly capable for most business needs), you have the flexibility to choose either. But if you ever want to use the model-driven experience — which gives you a lot of UI structure for free — Dataverse is your only option.

Side-by-Side: The Key Differences

Feature	SharePoint List	Dataverse
Cost	Included with Microsoft 365	Requires Power Apps Premium ($20/user/month)
Data structure	Flat, limited lookups	Full relational model
Max practical records	~100,000 before issues	Millions, no practical limit
Delegation support	Partial, tricky	Full, much more reliable
Security	Site/list/item level	Row, column, and role-based
Business logic	Basic validation only	Business rules, calculated & rollup columns
App types supported	Canvas Apps only	Canvas + Model-Driven Apps
ALM / Deployment	Hard to move together	Solution-aware, clean deployments
Offline support	No	Yes (mobile scenarios)
Setup complexity	Very easy	Moderate

So, When Should You Use SharePoint Lists?

Honestly, SharePoint lists are great for a lot of real-world scenarios. Don’t let anyone talk you out of them just because Dataverse sounds fancier.

Use a SharePoint list when:

• You’re building a simple departmental app — a leave tracker, an equipment request form, a visitor log
• Your data is unlikely to grow beyond a few thousand rows
• Your users already manage data in SharePoint and need direct access to it outside the app
• Cost is a constraint and you don’t have Premium licences
• You need to build something quickly and get it into people’s hands fast
• The app is tied to document management or SharePoint site content

I’d say the majority of small-to-medium business apps I’ve seen built by teams without dedicated developers are SharePoint-backed, and they work absolutely fine for their purpose.

And When Should You Use Dataverse?

Reach for Dataverse when the requirements start to outgrow what a list can handle.

Use Dataverse when:

• Your app will have more than 10,000–20,000 records and users need to filter and search across all of them
• You need relationships between multiple tables (e.g., projects → tasks → team members)
• The data is business-critical and you need proper audit trails and granular security
• You’re building for multiple user roles with different access levels
• You need to build a model-driven app
• You’re already using Dynamics 365, which means Dataverse is already part of your environment
• You want clean Application Lifecycle Management — moving your app and its data structure between dev, test, and production environments
• You need offline functionality for mobile users in the field

What About Licensing? Let’s Be Honest

This is the part that makes a lot of people hesitate on Dataverse, and fair enough.

SharePoint lists work with any standard Microsoft 365 licence. If your users have Microsoft 365 Business Basic, they’re good to go.

Dataverse requires a Power Apps Premium licence for every user who interacts with the app in production. As of 2025, that’s $20 per user per month (or $12/user/month at enterprise volumes of 2,000+ seats). There’s also a free Developer Plan if you just want to learn and build — it gives you 2 GB of Dataverse storage and full access to all features, but it’s for individual development use only, not production deployment.

The licence cost is real, and it’s worth factoring in before you commit. But if you’re building something that your organisation genuinely relies on — a business-critical process, something that handles sensitive data, or something that’s going to be used by hundreds of people — the extra cost per user is usually easy to justify.

A quick rule of thumb I use: if the broken app would cause a real business problem, invest in Dataverse. If the broken app would just be inconvenient, SharePoint list is probably fine.

My Recommendation for Getting Started

If you’re new to Power Apps and just getting your feet wet, start with a SharePoint list. The learning curve is gentler, there’s no extra cost, and you can build something useful in a day. Get comfortable with Power Apps as a tool before you add database concepts into the mix.

Once you start bumping into the limitations — delegation warnings, data getting stale, relationships getting messy — that’s your signal to look at Dataverse. And when you make the move, you’ll appreciate having a solid understanding of Power Apps already under your belt, because you’ll be able to focus on the data modelling rather than fighting the tool.

The two platforms aren’t really competitors. They’re different tools for different stages and different needs. Most mature Power Platform teams use both — SharePoint for quick wins and lightweight apps, Dataverse for anything that needs to scale or carry real business weight.

One Last Practical Tip

Before you build anything, ask yourself three questions:

1. How many records will this app have in 12 months? If the honest answer is “I have no idea, it could be a lot,” lean towards Dataverse.
2. Who needs to access what? If different users need different views of the same data with different permissions, Dataverse security is worth every penny.
3. Does this data relate to other data? If yes and you need that relationship to be reliable and queryable, don’t try to fake it with lookup columns in SharePoint.

Those three questions will point you in the right direction almost every time.

Also, you may like some more Power Apps and Dataverse tutorials:

• Dataflow in Dataverse
• Power Apps Image Control
• Power Apps Dataverse Yes/No Field
• Create Dataverse File Field
• Set Autonumber for Primary Name Column in Dataverse