Why would you use Dataverse, if SharePoint lists gives you the option to avoid premium licences?
Dataverse or SharePoint lists?
Table of Contents
Dataverse or SharePoint lists, that is the question.
There are a few things we have to consider when we try to answer the question.
- Data Volume
- Security
- Delegation
- Licence Cost
- Simplicity
- Development time
- Maintainability
- Connectors/APIs
Data volume
SharePoint is a great option if you want to store your data into simple lists and the data volume is small. Larger amounts of data in your list isn’t immediately a problem, but you might have to be a little cleverer in the way you build your apps and flows.
For larger solution you should quite often consider a database you could of course consider SQL server, however that quite quickly requires a DBA to be available. Adding new fields/columns becomes something that is quite a bit harder than in SharePoint.
one option that might then work is Dataverse. Dataverse is the data platform that comes with the Power Platform that doesn’t require a DBA. A Dataverse Administrator might be something that could help though 😉
Security
Especially if you want to secure items at an item level rather than a list level, you might find that you hit some limitations. Once you have too many items with unique permissions you will hit all sorts of difficult problems to solve.
Also, setting permissions in SharePoint form a Power App or a flow is not always the easiest thing to do.
Securing items within Dataverse is a bit better and isn’t as limited as in SharePoint.
another important point to consider is that items and documents in SharePoint can be referenced using a URL. So where you might think that hiding data from Search and making sure that users don’t know where your lists are is sufficient. If a user doesn’t get hold of a url to an item, they could potentially find the data held by other list items.
Comparing this to Dataverse, you will find that there isn’t a url that references a record in a table.
Delegation
Delegation is the option to send queries to your data source. These queries then get resolved within the data source before the results are returned. In my post about Delegation a while back, I mentioned the available options for SharePoint connections.
Delegation in SharePoint is slightly limited if you compare it to SQL server as I mentioned in my post a while back. So once again the volume of data can be something that is important to consider.
This simply means that your app or flow might have to do a bit more of the hard work.
Licence Cost
Absolutely none, well, that is you are already paying for it. To access SharePoint lists form the apps or flows doesn’t cost you anything extra.
Quite often this is the reason for people to choose SharePoint. But is that really right? Well, it all depends.
Simplicity
The creation of SharePoint list is definitely easier than the creation of Tables in Dataverse. That is of course if you are a user who is already used to using SharePoint lists.
No need to worry about solutions and no worries about complicated relationships. But when you really start to think about it, SharePoint lists can be copied from one site to another (e.g. using PnP PowerShell). And when you use lookups you can also have something that feels a bit like Relationships in Dataverse.
Development Time
Development time can be one of those hidden costs. If I assume for one moment that you are familiar with both SharePoint and Dataverse then the creation of Tables and lists is fairly similar. But what if you are familiar with one or the other? It might be quicker to develop lists or Tables in you personally preferred option.
Maintainability
Personally I like the idea of solutions in the Power Platform and I can’t wait for connections to be properly included in the solution deployment story.
When I have multiple environments and multiple SharePoint sites with identical lists. Using PnP PowerShell I can very quickly keep my different sites synchronized as I add new fields to my development version of the site. However I can’t easily bundle my data model and my apps in a single file. Yes, I sometimes do miss the good bits of the .wsp files that we used to have in SharePoint.
Connectors and APIs
When I compare the connectors for Dataverse and SharePoint. There is one very important factor
In SharePoint you can make 600 calls per minute to the connector, while in Dataverse you have 6000 in 5 minutes.
But there is more to consider within the connector.
Dataverse currently has 13 actions and 2 triggers in Power Automate
While SharePoint has a lot more. Especially the Send an HTTP request to SharePoint is useful when you want to use the API to do something that isn’t supported directly within the connector.
Maybe soon we will get an action to call the Dataverse Web API within the connector.
New in Dataverse!
This is a buit of a bonus at the end of this post. Last night the Common Data Service connector was finally to Dataverse.
Have you noticed the new icon?
So, which one wins Dataverse or SharePoint?
I would still say it all depends. For smaller solutions that will not grow (Do you still remember floppy disks and hard drives of 20MB that you would never fill?) you could use SharePoint. Also if your organisation is just getting started with Power Apps, then SharePoint might be a good option for a proof of concept project.
Unfortunately I still see licence cost, being the only thing that is considered. It’s a bit like getting a pack of paper and a pen to write a book, because that is cheaper than a laptop.
But for the more serious solutions that you might want to build I would consider using Dataverse instead.
[…] Why would you use Dataverse, if SharePoint lists gives you the option to avoid premium licences? Dataverse or SharePoint lists? Dataverse or SharePoint lists, that is the question. There are … Read More […]
Because SharePoint is not a relational database. I have seen so many developers base their design decisions on this false choice only to pay much more later when their SharePoint app is falling over because of the number of relationships they are managing in code, the volume of data in the various SharePoint lists, the number of app users and the amount of data being read, written, updated. When that SharePoint Enterprise app is failing at the wrong time and users are complaining, and failures are getting escalated so that now leaders multiple levels above you are aware of the poor decisions made, will you be able to defend those decisions?
If you are making a website or collaboration space or document management app, SharePoint is the tool. If you are building apps that will rely on a relational model, or apps that will create and use more than a few hundred rows of data, Dataverse or other relational datastore is the right choice.
The decision to choose SharePoint because it avoided a Power Apps license is a false choice. Bad architecture has a cost. Maintenance of bad design has a cost. Fine if your management will not approve the Power Apps license. Make sure your analysis and recommendations to them includes the cost of the technical debt you are creating as a result of a poor design decision.
@CoolMoG “If you are building apps that will rely on a relational model, or apps that will create and use more than a few hundred rows of data,”
SharePoint Online lists are fine for 5000 rows of data, maybe 50,000+, if you are reasonably clever about using filters in your views and Power Automate calls.
I don’t know, if you augment SharePoint a bit, it is plenty capable for a lot of things some may go to Dataverse for…
https://powerusers.microsoft.com/t5/Community-App-Samples/Large-SP-List-Delegation-Workaround-App/td-p/2330721
For small amounts of data SharePoint is ok. But as soon as you really want to use high volumes of data then Dataverse is the better option.
Also, if security is important I would pick Dataverse above SharePoint. Even though you can use SharePoint’s security features to hide the data sources from the user.
The huge benefit of SharePoint of course is that it is there as standard with the Microsoft 365 licences.