Case File: Is SharePoint a Database?
- Shane Young
- Sep 2
- 4 min read
Scene: A cold interrogation room. A single chair under a blinding light. Sitting in that chair? SharePoint. The crime it’s accused of? Pretending to be a database for Power Apps.
Let’s open the case file and see what the evidence says. But of course, if you prefer the full details in action, then check out my full-length video on Is SharePoint a Database?
Exhibit A: Can SharePoint Even Connect?
First things first: does SharePoint show up in Power Apps as a data source? Yep. You can add a SharePoint list, pull in records, and build screens. Personally, I still think this is the most common scenario for Canvas apps.
But wait, there is even more than you might notice at first glance. You can also connect to SharePoint Document Libraries. 🤯 And do you know where the absolute best place in the world to store files is for a Power Apps app? SharePoint. With your files stored there, instead of in a file column or even an attachment, you can leverage all of the power of Office Online to view and edit those files. Try editing a file stored in Dataverse or SQL, I will wait... yeah, not really a thing.
Exhibit B: Column Types
Traditional databases love complexity. SQL Server offers more data types than you’ll ever need (and probably a few you’ll never understand, I don't).
SharePoint? It keeps it simple. You don’t pick between decimal, int, and float, you just use Number. And SharePoint gives you Choice columns, which let users pick from a dropdown of values. SQL doesn’t have that out of the box.
Dataverse offers the best of both worlds but still gets a little confusing. In the end, SharePoint definitely wins the user-friendly award here.
Exhibit C: Relationships with SharePoint as a database
In SQL, setting up relationships means defining primary keys, foreign keys, and constraints. Powerful, yes but also super hard to do well.
SharePoint simplifies things with Lookup columns. If you want your Employees list to reference a Departments list? Just add a lookup and you’re done. No foreign keys required or understanding what that even means, it just works.
Dataverse does do this even better than SharePoint. The ability to dot notate your way through the relationship is awesome. It would be the winner if we were keeping score.
Exhibit D: Scale
This is where SharePoint’s story falls apart. The official documentation says a list can hold 30 million items. 🤣 Reality check? Not if you actually want to use them.
In practice, SharePoint is fine for a few thousand records when being used as a database. With indexed columns, maybe 25,000. But performance slows as the numbers climb. SQL and Dataverse, on the other hand, handle millions of rows without breaking a sweat.
Exhibit E: Security
SharePoint surprises us here. Unlike SQL, which usually manages security at the table level, SharePoint lets you configure row-level permissions. Not sure I would recommend you ever do this in SharePoint but technically possible.
Item-level security is not perfect; it is tedious and doesn’t scale well but the flexibility is there. Dataverse still has the most robust security model (table, row, column, and org-level), but it’s also the hardest to configure.
Exhibit F: ALM (Application Lifecycle Management)
Moving apps from dev to test to prod? SharePoint is the weak link. Lists don’t package nicely into solutions, and replicating schema across environments is a pain. Best answer might be to create your SharePoint lists with PowerShell but that is a lot of work, and new stuff to learn for many people.
Dataverse shines here with solutions, and SQL is straightforward with scripts. SharePoint? Let’s just say you don’t want to build a career on ALM with it.
Exhibit G: Normalization vs Reality
Every DBA loves normalization, splitting data into multiple tables with relationships. I know in college we literally spent 2 years on this concept. 🤮 But Power Apps doesn’t always love it. Heavily normalized data can slow your app way down.
SharePoint’s wide-table style (even with some repeated data) often makes apps faster and simpler. Sometimes the “bad database design” is actually the right choice for Power Apps performance. Don't shoot the messenger.
The Verdict
So, is SharePoint a database?
Yes, technically. It stores tabular data, supports relationships, and connects to Power Apps.
No, if you’re comparing it to SQL Server. It doesn’t scale or normalize the same way.
But who cares? In Power Apps, the real question is: does it meet the needs of your app?
SharePoint is the most popular Power Apps data source in the world, in my educated opinion. Largely because it’s included in Microsoft 365 licenses for Standard Power Apps. Dataverse and SQL are better for scale and ALM, but SharePoint is the “free” option that just works for thousands of makers.
So maybe we stop asking “Is SharePoint a database?” and start asking “Does SharePoint work for this app?”
Case closed.
If you’re wrestling with data sources in Power Apps, don’t go alone into the interrogation room. Hit that contact button and call in the pros. Sometimes all it takes is a quick 30-minute consult to crack the case, and other times we roll out the full PowerApps911 squad to build something big. Either way, we’ve solved thousands of cases just like yours and we’re always ready for the next investigation.