SharePoint as a Database: Is There a Better Option?

SharePoint has some similarities with databases. For example, like a database, it is used for storing and archiving files, and it can validate data that a user enters. Also, SharePoint utilizes the concept of document libraries, lists, columns and data types, which makes a repository look like a typical database structure.

However, that’s where the resemblance ends, as databases have more complex relationships between its records, columns and tables than SharePoint can ever support. One more thing that confuses users is that Microsoft SQL Server supports all content stored in SharePoint. And Microsoft SQL Server is actually a relational database management system.

Having 16-year experience in working with SharePoint, we can say with confidence that this platform is powerful when used for document management but it’s quite inept as database software. Below we provide the main reasons why SharePoint can’t serve as a full-fledged database.

Why is SharePoint no good as a database?

SharePoint can’t offer the same functionality as a database. Specifically, SharePoint lacks a number of basic database features that are responsible for collecting, storing, retrieving, sorting, graphing, and manipulating data in various ways. Here are some of the examples:

No database-like data organization

SharePoint doesn’t support complex data relationships typical of relational databases, such as:

• One-to-one. A record in one database table is related to only one record in another table. For example, a single employee can have only one ID number.
• One-to-many. A record in one table relates to many records in the second table. For example, one contract may relate to several business partners.
• Many-to-many. Each record in two tables can relate to any number of records in the other table. For example, a book can have several authors, and each author can have written several books.

These relationships are impossible in SharePoint. SharePoint list item IDs can’t be used to define relationships between different list items, just unlike primary and foreign keys, specific database identifiers, can do by linking tables.

No large volume of items and binary data

Unlike a database, SharePoint can’t handle many items. Even the SharePoint product team advises limiting the number of items in a list to 2,000 for each list container (the root of the list and any folders in the list), otherwise, the list performance significantly decreases. Also, SharePoint allows storing binary data only in the form of attachments to lists, while most modern databases fully support storing large binary files like video files, large volumes of text, images and more.

No transaction rollback

SharePoint doesn’t support the rollback of transactions. This means that in SharePoint environment, you can’t roll back changes if, for example, two changes are required to go together and the second change fails.

Consider a similar Microsoft platform for database creation

Although SharePoint rests on a database management system and has some similar functionality, the platform itself is not a database. If all you need is just structured and secure storage for several thousands of documents, SharePoint can easily meet your needs. But if you need a full-fledged database with an ability to store millions of files of multiple types with an ability to manage complex relationships between items, SharePoint is not your best choice.

In this regard, ScienceSoft recommends leveraging Microsoft Power Apps, a suite of low-code development software that offers out-of-the-box integration with SharePoint, Office 365, Microsoft Flow, and other Microsoft tools. Microsoft Power Apps can not only be used, similarly to SharePoint, to build diverse solutions from automated workflows to portals but also to enable citizen and pro developers to quickly create robust database-centric software. What's more, due to the integration of Power Apps with SharePoint, one can create database apps directly from a SharePoint list.