In this episode of the M365 Show, we unpack the most common Power Apps mistake in the Microsoft 365 ecosystem: assuming SharePoint is a “free database.” We break down why SharePoint lists look like a database, but architecturally behave like a file-centric collaboration layer—not a transactional data engine. From delegation limits to the infamous 2,000-record wall, we explain how apps built on SharePoint scale beautifully for a month… then collapse under load, concurrency, throttling and lookup chains. If you’ve ever heard “we’ll just use SharePoint for now,” this episode will save future performance pain. Learn what a real database is, how Dataverse and SQL handle indexing + relationships correctly, and why treating SharePoint like SQL is the fastest way to kill a Power App.

SharePoint is not a database solution. Many people mistakenly believe that SharePoint can serve as a full-fledged database, often fueled by the hype surrounding Power Apps integration. However, you must recognize that while SharePoint stores data, it lacks the essential features of a true database. Understanding these limitations is crucial before you choose SharePoint for data storage. Here are five key reasons to consider when evaluating SharePoint's capabilities.

Key Takeaways

SharePoint is primarily a content management system, not a database. Use it for document management and collaboration.
SharePoint lists have a 5,000 item limit for performance. Avoid using them for large datasets to prevent slowdowns.
SharePoint lacks true relational support. It cannot enforce data integrity like traditional databases.
Querying capabilities in SharePoint are basic. For complex data analysis, consider using a dedicated database.
Integration with other systems can be challenging. Manual data handling may lead to errors and inefficiencies.
Performance issues arise as data volume increases. Be cautious when using SharePoint for large-scale operations.
Explore alternatives like SQL Server or LumApps for better performance and relational support.
Evaluate your data needs carefully. Use SharePoint for collaboration, but choose a database for complex data management.

SharePoint Is Not a Database

SharePoint is not a database. It primarily serves as a content management system (CMS). This means its main purpose revolves around managing documents and facilitating collaboration among users. While you can store data in SharePoint, this does not equate to it functioning as a database.

Here are some key points to consider about SharePoint's role as a CMS:

SharePoint integrates well with Microsoft Office products, enhancing internal collaboration.
It provides version control and workflow capabilities, making it suitable for file sharing.
However, its flexibility as a comprehensive CMS is limited compared to specialized platforms.

Unlike a traditional database, SharePoint lacks the structured approach necessary for complex data management. A full-featured CMS offers structured content management capabilities, including workflow initiation and metadata management. SharePoint tracks basic document interactions but does not provide the depth of tracking functional activities related to documents that a dedicated CMS offers.

To further illustrate the differences, consider how data storage in SharePoint compares to a relational database like SQL Server. The following table highlights these distinctions:

Feature	SharePoint	SQL Server
Structure	Lists and columns	Tables and columns
Primary Key	Auto-increment ID column	Defined primary key
Foreign Key	Lookup columns	Foreign key constraints
Data Types	Various field types	Defined data types
Query Language	CAML	SQL
Event Handling	Event receivers	Triggers
Management Tool	SharePoint Manager	SQL Server Management Studio

As you can see, SharePoint's structure and capabilities differ significantly from those of a relational database. While it may seem convenient to use SharePoint as a database, doing so can lead to performance issues and limitations.

Data Structure Issues

SharePoint List Limitations

When you use SharePoint lists to store data, you face several important limitations. Although SharePoint lists can hold up to 30 million items, you will notice performance problems once your list grows beyond 5,000 items. This limit, called the list view threshold, restricts how many items you can query or display at one time. If your query returns more than 5,000 items, it will fail or slow down drastically. This makes SharePoint lists unsuitable for handling large datasets efficiently.

Additionally, each SharePoint list can have up to 276 columns. While this might seem like a lot, it still limits how much detail you can store in one list. Complex data often requires many fields, and hitting this column limit forces you to split data across multiple lists. This splitting complicates data management and reduces performance.

You should also consider that SharePoint lists do not handle complex queries well. When you try to filter or sort large lists, the system struggles, unlike a full-fledged database designed to optimize these operations. Backup and restore processes for large lists also take longer and are less reliable compared to databases like SQL Server or MySQL.

If you build apps with Power Apps using SharePoint lists as the backend, these limitations become even more apparent. Your app may work fine with small data sets but will slow down or fail as data grows. This is why SharePoint lists are not a substitute for a full-fledged database when your data needs grow.

Lack of Relational Support

A full-fledged database supports relationships between tables, allowing you to connect data logically and enforce data integrity. SharePoint lists, however, offer only basic lookup columns to link data. These lookups do not enforce referential integrity or support complex relational queries.

Without true relational support, you cannot easily model many-to-many relationships or perform joins across multiple lists. This limitation forces you to duplicate data or rely on complex workarounds, which increase the risk of errors and data inconsistency.

Databases like SQL Server use foreign keys and constraints to maintain relationships and ensure data accuracy. SharePoint lists lack these features, so you must manage relationships manually. This manual management adds overhead and increases the chance of mistakes.

When you use SharePoint lists as a backend for Power Apps, the lack of relational support limits your app’s functionality. You cannot build complex data models or enforce business rules effectively. This makes SharePoint lists a poor choice for applications that require robust data relationships.

Performance Challenges

Scaling Issues with SharePoint

SharePoint faces significant scaling challenges as your data volume increases. When you store large amounts of data, performance can degrade rapidly. For instance, SharePoint has a 5,000 item limit in document libraries. Exceeding this limit can lead to contention issues, causing delays in accessing libraries and hindering essential operations like copying or moving files.

The following table summarizes how various factors impact SharePoint's performance:

Factor	Impact on Performance
Database Size	Increased latency and contention
IOPS Requirements	Higher demands lead to performance degradation
Operational Limits	Exceeding thresholds causes delays

As the number of users grows, you will notice that activities like fetching user data and rendering membership take longer. The more users you have, the more time it takes for SharePoint to validate permissions. This can lead to frustrating delays, especially in collaborative environments.

Delegation Limits and Throttling

SharePoint imposes delegation limits that restrict how many records you can process at once. For example, when using Power Apps, you can only handle a limited number of records—typically 500 or 2,000—when a query is nondelegable. This limitation can lead to incomplete results, especially if your data source contains more records than the limit allows.

Throttling is another performance challenge in SharePoint. It acts as a protective mechanism but can slow down searches and lead to unpredictable performance. The following table illustrates the impact of throttling:

Impact of Throttling	Description
Reliability	Increased chances of query failures
Speed	Slower performance when processing large datasets

Throttling complicates planning and execution. You must account for potential delays and communicate these uncertainties to stakeholders. As your data grows, the unpredictability of throttling can hinder your ability to retrieve data efficiently.

Querying Limitations

Basic Query Capabilities

SharePoint's querying capabilities are quite basic, which limits your ability to analyze and report data effectively. You may find that while SharePoint can store data, it does not provide the depth needed for comprehensive analysis. Here are some key limitations you should be aware of:

Limitation	Description
High-Level Insights	SharePoint provides only basic insights, lacking depth for comprehensive analysis.
Limited Historical Data	You can only access data for a short period (e.g., 90 days), restricting trend analysis.
Scattered Data	Data is dispersed across various surfaces, complicating effective compilation and analysis.
Lack of User Segmentation	You cannot segment data by attributes like location or department, limiting targeted insights.
No Goal Tracking	The absence of features to track specific goals or conversions hinders performance measurement.
Need for Additional Tools	Many desired features require external tools or custom solutions, increasing complexity.

These limitations can hinder your ability to derive meaningful insights from your data. If you rely on SharePoint for reporting, you may need to invest in additional tools to fill these gaps.

No Advanced Query Support

The lack of advanced query support in SharePoint further complicates your ability to perform complex data operations. Here are some specific limitations and their impacts:

SharePoint Limitation	Impact on Complex Data Operations
5,000-item list view threshold	Limits dataset size and causes performance degradation, requiring extra configuration to avoid throttling, which hampers handling large or complex datasets.
No enforcement of referential integrity	Leads to inconsistent data across related entities, making it difficult to maintain data accuracy and build reliable complex data models.
Infrastructure not optimized for high query/transaction loads	Results in slow query performance and system slowdowns, restricting scalability and responsiveness needed for complex operations.
Limited support for complex data relationships and workflows	Prevents building sophisticated workflows or scalable data models, constraining your ability to streamline and scale data strategies.
Inconsistent and incomplete search functionality	Makes finding specific content difficult, further complicating complex data retrieval and operations.
Need for custom coding or third-party tools	Adds complexity and cost, increasing reliance on specialized support and reducing efficiency.

These factors can significantly impact your data management strategies. If you plan to use SharePoint as a backend for applications like Power Apps, be prepared for these challenges. The limitations in querying capabilities can lead to inefficiencies and frustration as your data needs grow.

Integration Difficulties

SharePoint as a Data Source

Using SharePoint as a data source presents several challenges. Many organizations struggle with integrating SharePoint into their existing systems for data storage and retrieval. Here are some common issues you might face:

Challenge	Description
Manual Data Handling	Employees must input data manually into different systems, leading to errors and inefficiencies.
Low Productivity	Switching between systems disrupts focus, reducing work efficiency and output.
Security Risks	Manual sharing of information increases vulnerabilities, risking unauthorized data access.
Delayed Decision-making	Scattered data makes it hard for leaders to access current information, delaying important decisions.
Legacy System Compatibility	Older systems may not integrate well with SharePoint, requiring custom solutions.
High Data Volumes	Large-scale operations generate massive data, complicating synchronization and causing performance issues.
Performance Bottlenecks	Slowdowns in one component can affect overall system performance, leading to delays in operations.

These challenges highlight that while SharePoint offers user-friendly interfaces, it lacks the advanced querying capabilities and performance optimization features found in traditional databases. SharePoint has poor scalability and performance when handling large data sets. It has a limit of 30 million items per list and 5,000 items per view. Exceeding these limits can cause errors, timeouts, and slow loading times.

Alternatives for Better Performance

If you find SharePoint's limitations too restrictive, consider exploring alternatives that offer better performance and integration capabilities. For instance, LumApps serves as an Employee Experience Platform (EXP) that enhances internal communication and engagement. Its modern interface and personalized newsfeeds drive employee engagement more effectively than SharePoint's traditional structure.

Another strong alternative is Unily, which targets large enterprises looking to modernize their digital workplace. It provides a secure and customizable environment that integrates seamlessly with Microsoft 365, Azure Active Directory, and Teams. This adaptability showcases its performance in data integration, making it a compelling choice for organizations seeking robust solutions.

Additionally, LumApps emphasizes a mobile-first experience, enhancing information adoption and employee connectivity. This advantage over SharePoint's more rigid intranet structure can significantly improve user engagement and data accessibility.

By considering these alternatives, you can ensure that your organization has the right tools to manage data effectively and efficiently.

You should remember these five reasons why SharePoint is not a database solution: it lacks true relational support, suffers from performance and scaling issues, offers limited querying capabilities, faces integration challenges, and is designed primarily for collaboration and document management.

Feature	SharePoint Capability	Traditional Database Solutions
Append-Only Storage	Ensures files cannot be changed after saving	Varies by implementation
Versioning	Retains multiple versions, configurable	Often less flexible
Metadata Resilience	Critical for user content access	Depends on database design
Point in Time Restore	Allows recovery within last 30 days	Varies, often limited

Experts recommend you use SharePoint for secure document storage with proper permissions but rely on traditional databases for complex data relationships and large volumes. You should establish strong data governance, enforce permissions carefully, and choose solutions that fit your data needs. Making informed technology choices now helps you avoid costly issues later.

Tip: Always evaluate your data complexity and growth before deciding. SharePoint excels at collaboration but not at managing transactional or relational data.

FAQ

What makes a true database different from SharePoint?

A true database supports complex relationships, enforces data integrity, and handles large volumes efficiently. SharePoint stores data but lacks these core database features, making it unsuitable for complex data management.

Can I use SharePoint lists for small database needs?

Yes, SharePoint lists work for simple, small datasets. However, as your data grows, you will face performance and querying limits that databases handle better.

Why does SharePoint slow down with more than 5,000 items?

SharePoint has a list view threshold of 5,000 items to protect performance. Queries beyond this limit slow down or fail, unlike databases designed to scale with large data.

Does SharePoint support relational data like databases?

No, SharePoint only offers basic lookup columns without enforcing relationships or referential integrity. Databases use keys and constraints to maintain accurate, connected data.

What happens when SharePoint hits delegation limits in Power Apps?

Delegation limits restrict how many records Power Apps can process from SharePoint. This causes incomplete data retrieval and slows app performance, unlike databases that handle large queries efficiently.

Are there better alternatives to SharePoint for database needs?

Yes, databases like SQL Server or Dataverse provide robust relational support, scalability, and advanced querying. These solutions fit complex data needs better than SharePoint.

Can SharePoint handle transactional data like a database?

No, SharePoint lacks transactional support. Databases manage transactions to ensure data consistency during multiple operations, which SharePoint cannot guarantee.

How should I decide between SharePoint and a database?

Assess your data complexity, volume, and relational needs. Use SharePoint for collaboration and document storage. Choose a database when you need reliable, scalable data management.

🚀 Want to be part of m365.fm?

Then stop just listening… and start showing up.

👉 Connect with me on LinkedIn and let’s make something happen:

🎙️ Be a podcast guest and share your story
🎧 Host your own episode (yes, seriously)
💡 Pitch topics the community actually wants to hear
🌍 Build your personal brand in the Microsoft 365 space

This isn’t just a podcast — it’s a platform for people who take action.

🔥 Most people wait. The best ones don’t.

👉 Connect with me on LinkedIn and send me a message:
"I want in"

Let’s build something awesome 👊

Opening: The False Comfort of “Free Databases”You’ve heard this phrase before—casually dropped into Microsoft Teams calls with frightening confidence—“Oh, we’ll just use SharePoint as the database for our Power App.”And there it is. The modern cry of the overconfident citizen developer.This, right here, is the problem. People hear “data stored somewhere” and immediately conclude “database.” By that logic, your junk drawer is a supply chain management system.The confusion is forgivable, barely. SharePoint does hold data, and Power Apps can read it. But that does not make it a database any more than Excel becomes a server when you save two worksheets.Average users love the illusion. SharePoint lists look structured. They have columns and rows, fields and filters. And of course—it’s already included in Microsoft 365, so it must be good enough, right?Wrong. You’re about to see why the “free” database sitting in your tenant is a performance time bomb disguised as convenience.By the end, you’ll understand why Power Apps that begin with “just SharePoint” eventually die gasping under their own weight—and why treating it like SQL is the digital equivalent of trusting a filing cabinet to run an engine.Section 1: What a Database Actually IsLet’s reset the definitions before your app implodes. A proper database isn’t just a bucket that holds information. It’s a system built on architecture and logic. It has order, schema, indexing, relationships, and concurrency control—the invisible infrastructure that lets dozens or thousands of users read, write, and query your data without tripping over each other.SQL Server and Dataverse handle this beautifully. Schemas define the blueprint—every column type and constraint serves like support beams in a skyscraper. Indexes act as the elevator shafts that get you exactly where you need, fast. Relationships keep records consistent, ensuring that when one table sneezes, its related tables say “bless you” in perfect synchronization.Now compare that to SharePoint. SharePoint was not designed to manage transactions at scale. Its DNA is collaboration, version history, permissions, and file storage. It’s more like a glorified document librarian than a record-keeping accountant. It’s wonderful at organizing text, attachments, and metadata—but call it a database, and you might as well call your filing cabinet a “data processing engine.”Real databases think in joins, referential integrity, and execution plans. SharePoint thinks in lists, permissions, and column choices written by someone who definitely didn’t study relational theory. It’s a web layer optimized for people, not for queries.Here’s where the Power Apps confusion begins. The app happily connects to SharePoint through an OData connector. You can create forms, galleries, and dashboards. On the surface, everything looks professional. The danger is invisible—until your app grows.I once met a department that proudly built their internal CRM entirely on top of four SharePoint lists. It worked beautifully—for a month. Then came the fifth thousand record. Suddenly the app stuttered, screens froze, and every gallery took half a minute to load. Their users thought the problem was “bad Wi‑Fi.” It wasn’t Wi‑Fi. It was physics. SharePoint was trying to impersonate a relational database.The truth? Power Apps can connect to SharePoint, but that’s all it does—connect. It borrows the data source, but it doesn’t make SharePoint any smarter. There’s no hidden engine under the surface waiting to optimize your queries.Imagine trying to race with a car built from bicycle parts. Sure, it has wheels. It moves. But once you hit highway speeds, bolts start flying. The handlebars—the list structure—were never designed to steer that kind of load.Dataverse, in contrast, is a proper engine. It’s transactional, relational, optimized for delegation, and built for Power Platform from the ground up. It follows database logic, not just storage logic. That’s the difference between structured speed and unstructured sprawl.SharePoint has indexing—but limited. It has lookup columns—but no genuine referential constraints. It allows multiple users—but not graceful concurrency handling. You can write to it, but if three users edit the same record at once, one loses. Usually the intern.Essentially, a database enforces integrity while SharePoint hopes for good behavior. SQL refuses to accept invalid relationships. SharePoint accepts everything, smiles politely, and breaks quietly months later.If this still feels theoretical, don’t worry. Scale will make it painfully real. Because while architecture can be ignored for a while, performance cannot. And as your user base grows, your “database” made from friendly SharePoint lists will groan like a spreadsheet with delusions of grandeur.The next part is where the collapse begins: Microsoft’s shiny number—30 million items—and the cruel joke hiding behind it. Let’s talk about scale, the silent killer of every Power App that mistook convenience for capability.Section 2: The Scale MythMicrosoft loves big numbers. Nothing sells confidence like a glossy documentation page claiming your SharePoint list can hold—wait for it—thirty million items. Sounds impressive, doesn’t it? Thirty million entries! You could store the payroll history of an empire. The problem is that the number is marketing, not math. That limit describes what SharePoint can physically contain, not what it can functionally handle. It’s like saying a washing machine can technically fit ten bowling balls. True. Until you press start.In reality, the moment those lists creep beyond a few thousand records, Power Apps begins its slow descent into misery. Buttons take seconds to respond. Galleries forget how to scroll smoothly. You click “Filter,” and the spinning dots start an existential performance art piece. By ten thousand records, it feels like wading through syrup. Beyond that, you’re practically time‑traveling—all the way back to dial‑up.The core culprit here is a polite little concept called delegation. It’s Power Apps’ way of saying, “I can’t handle that query locally, so I’ll ask the data source to compute it for me.” SharePoint, however, isn’t fluent in that language. Its delegation capabilities are minimal. Translation: anything outside a small set of filter and sort operations is pulled locally. The data comes down the wire, record by record, so your client device ends up doing the heavy lifting a real database engine would have done in milliseconds. You built an enterprise app, and now every user’s laptop is its database server. Congratulations.The infamous 2,000‑item delegation wall isn’t a myth—it’s a design constraint. Unless you use creative (and usually fragile) pagination workarounds, Power Apps simply refuses to process more. You can raise that ceiling a little with clever queries, but eventually the data set expands faster than the platform can pretend nothing’s wrong. Even if you index your columns—the supposed magic trick—things only improve marginally. Like upgrading a rubber band with a thicker rubber band.Microsoft’s documentation hints that indexing can let you manage up to around 25,000 records if you’re “careful.” Translation: it will technically work while producing the user experience of a PowerPoint slideshow transmitted over carrier pigeons. The indexes prevent total collapse but can’t change the fact that SharePoint stores data in what is essentially a flattened web table. Each query becomes a request for a giant JSON blob, parsed piece by piece. SQL or Dataverse, by contrast, sends back neat pre‑processed chunks of matching rows. SharePoint just hands you everything and says, “Good luck sorting it.”Every extra thousand records adds latency. It’s not linear—it’s exponential. One thousand rows? Acceptable. Ten thousand? Noticeable lag. Twenty thousand? Every gallery becomes a meditation exercise. Users start clicking twice, thinking their devices froze, which of course triggers double updates and conflicting writes. That’s when someone suggests “maybe we should rebuild this in Excel,” and the circle of bad decisions completes itself.Using SharePoint as a back‑end at scale is like powering a data center with AA batteries. Each small operation works, barely. But time and concurrency amplify the load until the whole thing starts coughing. The connectors try to fetch data while maintaining security context, evaluating filters, and managing throttling—all over cloud HTTP calls that multiply faster than your patience decreases. Meanwhile, Dataverse or SQL would be compressing, caching, and delegating queries natively. SharePoint’s response to that level of complexity? A polite shrug followed by a timeout.And don’t forget throttling. Once you exceed certain thresholds in Office 365, SharePoint starts limiting the number of requests per user per minute. It doesn’t warn you nicely—it simply refuses to serve data for a few seconds. Multiply that delay by hundreds of active users, and you’ve turned your business app into a queue simulator. Remember: throttling isn’t failure; it’s SharePoint’s polite way of begging you to stop abusing it.Now, let’s add relationships into the mix. Many creators think scaling problems vanish if they just break lists apart. “We’ll have one for Customers, one for Orders, one for Products, and link them.” Fascinating optimism. Each lookup between those lists triggers its own set of API calls. So, when you open a single record, you’re actually launching dozens of hidden queries. Multiply that by hundreds of users, and your app starts behaving like a chain smoker climbing stairs. Power Apps will valiantly try to batch requests, but latency stacks faster than performance optimizers can patch it.What’s particularly cruel is how invisible the decay feels at first. Everything seems fine—until the day new data pushes you past that unseen tipping point. Then screens freeze. Connections fail silently. Eventually, developers start layer

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-podcast--6704921/support.

Follow us on:
LInkedIn
Substack

WEBVTT

1
00:00:00.080 --> 00:00:03.120
You've heard this phrase before, casually dropped into Microsoft teams

2
00:00:03.120 --> 00:00:06.759
calls with frightening confidence. Oh, we'll just use SharePoint as

3
00:00:06.799 --> 00:00:09.160
the database for our power app. And there it is

4
00:00:09.400 --> 00:00:12.199
the modern cry of the over confidence citizen developer. This

5
00:00:12.519 --> 00:00:14.839
right here is the problem. People here at data stored

6
00:00:14.880 --> 00:00:18.719
somewhere and immediately conclude database. By that logic, your junk

7
00:00:18.800 --> 00:00:21.640
draw is a supply chain management system. The confusion is

8
00:00:21.719 --> 00:00:25.239
forgivable barely. SharePoint does hold data and power apps can

9
00:00:25.280 --> 00:00:27.600
read it, but that does not make it a database

10
00:00:27.640 --> 00:00:30.480
anymore than Excel becomes a server when you save two worksheets.

11
00:00:30.559 --> 00:00:33.799
Average users love the illusion. SharePoint lists look structured. They

12
00:00:33.799 --> 00:00:36.640
have columns and rows, fields and filters, and of course

13
00:00:36.679 --> 00:00:39.200
it's already included in Microsoft three sixty five, so it

14
00:00:39.280 --> 00:00:41.880
must be good enough. Right. Wrong. You're about to see

15
00:00:41.880 --> 00:00:44.240
why the free database sitting in your tenant is a

16
00:00:44.240 --> 00:00:47.679
performance time bomb disguised as convenience. By the end, you'll

17
00:00:47.719 --> 00:00:50.960
understand why power apps that begin with just SharePoint eventually

18
00:00:51.000 --> 00:00:53.799
die gasping under their own weight, and why treating it

19
00:00:53.880 --> 00:00:56.479
like sickle is the digital equivalent of trusting a filing

20
00:00:56.520 --> 00:00:59.759
cabinet to run an engine. What a database actually is.

21
00:01:00.079 --> 00:01:03.159
Let's reset the definitions before your app implodes. A proper

22
00:01:03.240 --> 00:01:05.840
database isn't just a bucket that holds information. It's a

23
00:01:05.879 --> 00:01:10.799
system built on architecture and logic. It has order, schema, indexing, relationships,

24
00:01:10.840 --> 00:01:14.439
and concurrency control the invisible infrastructure that leads dozens or

25
00:01:14.480 --> 00:01:17.719
thousands of users read, write, and query your data without

26
00:01:17.760 --> 00:01:20.840
tripping over each other. Sequel server and data verse handle

27
00:01:20.879 --> 00:01:24.280
this beautifully. Skimmers define the blueprint, every column type and

28
00:01:24.359 --> 00:01:27.640
constraint serves like support beams in a skyscraper. Indexes act

29
00:01:27.719 --> 00:01:30.200
as the elevator shafts that get you exactly where you need.

30
00:01:30.400 --> 00:01:34.920
Fast relationships, keep records consistent, ensuring that when one table sneezes,

31
00:01:35.280 --> 00:01:38.840
its related tables say bless you in perfect synchronization. Now

32
00:01:38.879 --> 00:01:41.680
compare that to SharePoint. SharePoint was not designed to manage

33
00:01:41.680 --> 00:01:45.640
transactions at scale. Its DNA is collaboration, version, history, permissions,

34
00:01:45.640 --> 00:01:48.480
and file storage. It's more like a glorified document librarian

35
00:01:48.519 --> 00:01:51.840
than a record keeping accountant. It's wonderful at organizing text,

36
00:01:51.840 --> 00:01:54.760
attachments and metadata. But call it a database and you

37
00:01:54.840 --> 00:01:57.840
might as well call your filing cabinet a data processing engine.

38
00:01:58.120 --> 00:02:01.879
Real databases think in joints, rev rntial integrity and execution plans.

39
00:02:02.040 --> 00:02:05.439
SharePoint thinks in lists, permissions, and column choices written by

40
00:02:05.480 --> 00:02:08.599
someone who definitely didn't study relational theory. It's a web

41
00:02:08.680 --> 00:02:11.520
layer optimized for people, not for queries. Here's where the

42
00:02:11.520 --> 00:02:15.039
power apps confusion begins. The app happily connects to SharePoint

43
00:02:15.039 --> 00:02:18.080
through an data connector. You can create forms, galleries, and dashboards.

44
00:02:18.120 --> 00:02:21.120
On the surface, everything looks professional. The danger is invisible

45
00:02:21.319 --> 00:02:23.800
until your app grows. I once met a department that

46
00:02:23.919 --> 00:02:26.800
proudly built their internal CRM entirely on top of four

47
00:02:26.800 --> 00:02:30.039
SharePoint lists. It worked beautifully for a month, then came

48
00:02:30.039 --> 00:02:33.719
the fifth thousand record. Suddenly the apps stuttered, screens froze,

49
00:02:33.719 --> 00:02:36.240
and every gallery took half a minute to load. Their

50
00:02:36.319 --> 00:02:39.360
users thought the problem was bad Wi Fi. It wasn't

51
00:02:39.400 --> 00:02:42.280
Wi fi, it was physics. SharePoint was trying to impersonate

52
00:02:42.280 --> 00:02:46.000
a relational database. The truth. Power apps can connect to SharePoint,

53
00:02:46.000 --> 00:02:48.439
but that's all it does. Connect. It borrows the data source,

54
00:02:48.479 --> 00:02:51.039
but it doesn't make SharePoint any smarter. There's no hidden

55
00:02:51.039 --> 00:02:54.199
engine under the surface waiting to optimize your queries. Imagine

56
00:02:54.199 --> 00:02:56.400
trying to raise with a car built from bicycle parts.

57
00:02:56.479 --> 00:02:58.919
Sure it has wheels, it moves, but once you hit

58
00:02:59.000 --> 00:03:02.879
highway speeds, bolts start flying the handlebars. The list structure

59
00:03:03.159 --> 00:03:06.000
where never designed to steer that kind of load. Data Verse,

60
00:03:06.120 --> 00:03:09.759
in contrast, is a proper engine. Its transactional, relational, optimized

61
00:03:09.759 --> 00:03:12.719
for delegation and built for power platform from the ground up.

62
00:03:12.840 --> 00:03:16.199
It follows database logic, not just storage logic. That's the

63
00:03:16.240 --> 00:03:20.319
difference between structured speed and unstructured sprawl. SharePoint has indexing,

64
00:03:20.439 --> 00:03:23.360
but limited. It has look up columns, but no genuine

65
00:03:23.400 --> 00:03:27.960
referential constraints. It allows multiple users, but not graceful concurrency handling.

66
00:03:28.439 --> 00:03:30.280
You can write to it, but if three users added

67
00:03:30.319 --> 00:03:35.159
the same record at once, one loses usually the intern Essentially,

68
00:03:35.280 --> 00:03:39.039
a database enforces integrity. While SharePoint hopes for good behavior,

69
00:03:39.159 --> 00:03:44.000
Circle refuses to accept invalid relationships. SharePoint accepts everything, smiles politely,

70
00:03:44.199 --> 00:03:47.520
and breaks quietly. Months later. If this still feels theoretical,

71
00:03:47.560 --> 00:03:50.400
don't worry. Scale will make it painfully real, because while

72
00:03:50.479 --> 00:03:53.159
architecture can be ignored for a while, performance cannot, and

73
00:03:53.199 --> 00:03:56.080
as your user base grows, your database made from friendly

74
00:03:56.120 --> 00:03:59.840
SharePoint lists will groan like a spreadsheet with delusions of grandeur.

75
00:04:00.400 --> 00:04:03.560
The next part is where the collapse begins. Microsoft's shiny

76
00:04:03.639 --> 00:04:07.000
number thirty million items and the cruel joke hiding behind it.

77
00:04:07.159 --> 00:04:09.919
Let's talk about scale, the silent killer of every power

78
00:04:09.960 --> 00:04:14.039
app that mistook convenience for capability, the scale myth. Microsoft

79
00:04:14.120 --> 00:04:17.839
loves big numbers. Nothing sells confidence like a glossy documentation

80
00:04:17.959 --> 00:04:20.879
page claiming your share Point list can hold wait for it,

81
00:04:20.959 --> 00:04:24.279
thirty million items sounds impressive, doesn't it. Thirty million entries

82
00:04:24.519 --> 00:04:26.480
you could store the payroll history of an empire. But

83
00:04:26.519 --> 00:04:29.000
the problem is that the number is marketing, not math.

84
00:04:29.279 --> 00:04:32.600
That limit describes what share Point can physically contain, not

85
00:04:32.720 --> 00:04:35.839
what it can functionally handle. It's like saying a washing

86
00:04:35.879 --> 00:04:39.319
machine can technically fit ten bowling balls. True until you

87
00:04:39.360 --> 00:04:42.160
press start. In reality, the moment those lists creep beyond

88
00:04:42.160 --> 00:04:45.199
a few thousand records, power apps begins its slow descent

89
00:04:45.240 --> 00:04:48.680
into misery. Buttons take seconds to respond. Galleries forget how

90
00:04:48.720 --> 00:04:51.600
to scroll smoothly. You click filter and the spinning dots

91
00:04:51.600 --> 00:04:54.879
start an existential performance art piece by ten thousand records.

92
00:04:54.879 --> 00:04:57.800
It feels like wading through syrup. Beyond that, you're practically

93
00:04:57.800 --> 00:05:00.560
time traveling all the way back to dial up. The

94
00:05:00.600 --> 00:05:03.399
core culprit here is a polite little concept called delegation.

95
00:05:03.519 --> 00:05:06.079
It's power App's way of saying, I can't handle that

96
00:05:06.160 --> 00:05:08.680
query locally, so I'll ask the data source to compute

97
00:05:08.720 --> 00:05:11.959
it for me. SharePoint, however, isn't fluent in that language.

98
00:05:12.079 --> 00:05:15.839
Its delegation capabilities are minimal. Translation anything outside a small

99
00:05:15.839 --> 00:05:18.600
set of filter and sought operations is pulled locally. The

100
00:05:18.680 --> 00:05:20.959
data comes down the wire record by records, so your

101
00:05:20.959 --> 00:05:23.199
client device ends up doing the heavy lifting a real

102
00:05:23.279 --> 00:05:26.040
database engine would have done in milliseconds. You built an

103
00:05:26.160 --> 00:05:30.399
enterprise app, and now every user's laptop is its database server. Congratulations.

104
00:05:31.759 --> 00:05:34.519
The infamous two thousand item delegation wall isn't a myth.

105
00:05:34.600 --> 00:05:38.040
It's a design constraint. Unless you use creative and usually

106
00:05:38.079 --> 00:05:42.360
fragile pagination workarounds, power App simply refuses to process more.

107
00:05:42.480 --> 00:05:44.639
You can raise that ceiling a little with clever queries,

108
00:05:44.839 --> 00:05:47.600
but eventually the data set expands faster than the platform

109
00:05:47.600 --> 00:05:50.240
can pretend nothing's wrong. Even if you index your columns

110
00:05:50.279 --> 00:05:53.879
the supposed magic trick, things only improve marginally, like upgrading

111
00:05:53.920 --> 00:05:57.040
a rubber band with a thicker rubber band. Microsoft's documentation

112
00:05:57.160 --> 00:05:59.240
hints that indexing can let you manage up to around

113
00:05:59.240 --> 00:06:02.920
twenty five thousand records if you're careful. Translation it will

114
00:06:02.920 --> 00:06:06.240
technically work while producing the user experience of a PowerPoint

115
00:06:06.240 --> 00:06:10.160
slide show transmitted over carrier pigeons. The indexes prevent total collapse,

116
00:06:10.199 --> 00:06:12.639
but can't change the fact that SharePoint stores data in

117
00:06:12.680 --> 00:06:15.680
what is essentially a flattened web table. Each query becomes

118
00:06:15.720 --> 00:06:18.600
a request for a giant Jason blob passed piece by piece,

119
00:06:19.000 --> 00:06:21.959
squirrel or data verse by contrast sends back neat pre

120
00:06:22.000 --> 00:06:25.120
processed chunks of matching rows. SharePoint just hands you everything

121
00:06:25.120 --> 00:06:28.040
and says good luck sorting it. Every extra thousand records

122
00:06:28.079 --> 00:06:32.639
adds latency. It's not linear, it's exponential. One thousand rows acceptable,

123
00:06:33.120 --> 00:06:36.439
ten thousand noticeable lag twenty thousand. Every gallery becomes a

124
00:06:36.480 --> 00:06:40.399
meditation exercise. Users start clicking twice, thinking their devices froze,

125
00:06:40.399 --> 00:06:43.399
which of course triggers double updates and conflicting rights. That's

126
00:06:43.439 --> 00:06:46.360
when someone suggests, maybe we should rebuild this in Excel,

127
00:06:46.879 --> 00:06:50.160
and the circle of bad decisions completes itself. Using SharePoint

128
00:06:50.160 --> 00:06:51.879
as a back end at scale is like powering a

129
00:06:51.959 --> 00:06:55.560
data center with AA batteries. Each small operation works barely,

130
00:06:55.839 --> 00:06:58.399
but time and concurrency amplify the load until the whole

131
00:06:58.399 --> 00:07:01.240
thing starts coughing the connect Try to fetch data while

132
00:07:01.279 --> 00:07:05.120
maintaining security, context, evaluating filters, and managing throttling all over

133
00:07:05.199 --> 00:07:09.560
cloud http calls that multiply faster than your patients decreases. Meanwhile,

134
00:07:09.680 --> 00:07:13.240
Data Verse or SQUAL would be compressing, caching, and delegating

135
00:07:13.279 --> 00:07:16.720
queries Natively. Share Points response to that level of complexity

136
00:07:16.879 --> 00:07:19.360
a polite shrug followed by a timeout, and don't forget

137
00:07:19.360 --> 00:07:22.519
throttling once you exceed certain thresholds. In Office three sixty five,

138
00:07:22.600 --> 00:07:25.920
Sharepoints starts limiting the number of requests per user per minute.

139
00:07:26.079 --> 00:07:28.800
It doesn't warn you nicely, it simply refuses to serve

140
00:07:28.879 --> 00:07:31.920
data for a few seconds. Multiply that delay by hundreds

141
00:07:31.920 --> 00:07:34.560
of active users, and you've turned your business app into

142
00:07:34.560 --> 00:07:38.560
a queue simulator. Remember, throttling isn't failure. It's share points

143
00:07:38.560 --> 00:07:40.879
polite way of begging you to stop abusing it. Now,

144
00:07:40.959 --> 00:07:44.079
let's add relationships into the mix. Many creators think scaling

145
00:07:44.079 --> 00:07:46.759
problems vanish if they just break lists apart. We'll have

146
00:07:46.800 --> 00:07:49.399
one for customers, one for orders, one for products and

147
00:07:49.480 --> 00:07:53.040
link them fascinating optimism. Each look up between those lists

148
00:07:53.199 --> 00:07:56.519
triggers its own set of API calls, So when you

149
00:07:56.560 --> 00:07:59.680
open a single record, you're actually launching dozens of hidden queries.

150
00:08:00.040 --> 00:08:02.639
Apply that by hundreds of users, and your app starts

151
00:08:02.639 --> 00:08:06.240
behaving like a chainsmoker climbing stairs. Power apps will valiantly

152
00:08:06.319 --> 00:08:09.199
try to batch requests, but latency stacks faster than performance

153
00:08:09.199 --> 00:08:12.680
optimizers can patch it. What's particularly cruel is how invisible

154
00:08:12.680 --> 00:08:16.000
the decay feels. At first. Everything seems fine until the

155
00:08:16.079 --> 00:08:18.959
day new data pushes you past that unseen tipping point.

156
00:08:19.240 --> 00:08:25.040
Then screens freeze, connections fail silently. Eventually, developers start layering

157
00:08:25.079 --> 00:08:29.000
patchwork fixes, smaller galleries, manual catching, collection tricks to load

158
00:08:29.040 --> 00:08:32.240
subsets of data. It looks like progress, but only delays

159
00:08:32.279 --> 00:08:34.679
the inevitable. It's like rearranging deck chairs on a server

160
00:08:34.759 --> 00:08:38.200
farm that's on fire. People mistake reliability for survival time.

161
00:08:39.000 --> 00:08:42.600
It's worked for months, they say, proudly, ignoring the trend line.

162
00:08:42.679 --> 00:08:46.799
A proper database scales predictably. More data means slightly more storage,

163
00:08:47.000 --> 00:08:51.639
not exponentially slower queries, SharePoint scales emotionally. It starts healthy.

164
00:08:51.840 --> 00:08:54.240
Then suddenly collapses like it just remembered it's a web

165
00:08:54.279 --> 00:08:57.559
service from two thousand and three, and yet the illusion persists.

166
00:08:57.600 --> 00:09:01.480
Because Microsoft includes SharePoint in the license, the tool is approachable,

167
00:09:01.519 --> 00:09:04.279
the set up effortless, and the first prototype thrillingly quick,

168
00:09:04.480 --> 00:09:10.200
but free convenience hides catastrophic economics. Each delay compounds across users, departments,

169
00:09:10.200 --> 00:09:14.440
and workflows until productivity losses dwarf any licensing savings. The

170
00:09:14.480 --> 00:09:17.879
irony the organization eventually pays far more for an included

171
00:09:17.919 --> 00:09:19.919
feature than it would have for data versus so called

172
00:09:19.960 --> 00:09:23.600
premium price. You wanted relational joints across lists fascinating, Do

173
00:09:23.639 --> 00:09:26.639
you also expect teleportation because that's about as plausible Inside

174
00:09:26.679 --> 00:09:30.600
Sharepoints architecture, the list interface wasn't built for transactional queries

175
00:09:30.679 --> 00:09:33.960
or complex aggregation. It's a collaborative document store that's being

176
00:09:34.000 --> 00:09:37.360
forced daily to impersonate a relational database. No wonder it

177
00:09:37.399 --> 00:09:40.120
looks tired. So the next time someone quotes that thirty

178
00:09:40.159 --> 00:09:43.200
million item limit, pause, ask them how many they've actually

179
00:09:43.279 --> 00:09:46.840
queried successfully in power apps without freezing the app. The

180
00:09:46.919 --> 00:09:49.679
number will be much smaller, somewhere between few thousand and

181
00:09:49.720 --> 00:09:52.919
Please don't ask. That's not scale. That's tolerance, and tolerance

182
00:09:52.960 --> 00:09:55.360
runs out. What follows it is the crash every power

183
00:09:55.360 --> 00:09:58.799
app team eventually experiences the day their free database becomes

184
00:09:58.799 --> 00:10:01.799
a very expensive bottlenet. The visible slowdown is just the start.

185
00:10:01.960 --> 00:10:04.279
What comes next is subtler, the kind of corruption hidden

186
00:10:04.279 --> 00:10:07.080
behind seemingly normal forms and look ups. Because while performance

187
00:10:07.120 --> 00:10:10.240
pain screams, integrity failure whispers, and in the next section

188
00:10:10.279 --> 00:10:14.600
those whispers turn into full blown data chaos, relationships, look ups,

189
00:10:14.679 --> 00:10:17.639
and other dangerous illusions. Now we reach the part where

190
00:10:17.759 --> 00:10:21.240
SharePoint proudly pretends to be relational. It waives its little

191
00:10:21.240 --> 00:10:24.519
look up column and declares, c I can do relationships too. No,

192
00:10:24.639 --> 00:10:27.039
you can't, not the kind that mattered, Not the kind

193
00:10:27.080 --> 00:10:31.639
with referential integrity, cascading updates, and proper foreign keys. What

194
00:10:31.720 --> 00:10:34.399
SharePoint offers is a child's drawing of a database scribbled

195
00:10:34.399 --> 00:10:37.519
in crayon, queued from a far horrifying up close in

196
00:10:37.559 --> 00:10:40.759
a real database. Relationships are contracts. Table A promises to

197
00:10:40.799 --> 00:10:43.240
link only to valid records in table B. If you

198
00:10:43.320 --> 00:10:46.559
delete something in B, the database enforces. What happens next

199
00:10:46.679 --> 00:10:50.480
either block it, cascaded, or update accordingly. Integrity is law.

200
00:10:51.039 --> 00:10:55.480
Share Point by contrast, treats relationships as gossip. I heard

201
00:10:55.519 --> 00:10:58.279
record X, might know record why, but who can say really?

202
00:10:58.759 --> 00:11:01.000
Delete the parent list item and the child keeps an

203
00:11:01.080 --> 00:11:03.960
orphaned reference quietly rotting until a user clicks it and

204
00:11:04.000 --> 00:11:06.600
gets an error that looks like a riddle. Developers cling

205
00:11:06.679 --> 00:11:09.960
to look up columns thinking they're safe, and they're not relationships.

206
00:11:09.960 --> 00:11:12.399
They're lightweight pointers that store the ID and a bit

207
00:11:12.440 --> 00:11:15.639
of display text, nothing more. They don't validate consistency, they

208
00:11:15.639 --> 00:11:18.720
don't prevent duplicates. They simply assume nothing will go wrong,

209
00:11:18.759 --> 00:11:21.720
which is adorable. And when power apps uses those lookups,

210
00:11:21.759 --> 00:11:24.600
it has to perform multiple calls, one to retrieve the

211
00:11:24.639 --> 00:11:27.600
main list, another to resolve each look up. That's dozens

212
00:11:27.600 --> 00:11:30.080
of round trips just to reconstruct what cycle would fetch

213
00:11:30.120 --> 00:11:33.240
in one joint. Every lookup adds lag, every nested gallery

214
00:11:33.279 --> 00:11:36.039
doubles it. Choice columns are equally misleading. They look like

215
00:11:36.120 --> 00:11:39.440
constraint enforcement preset options, clean new eye, but under the

216
00:11:39.480 --> 00:11:42.879
hood their glorified text fields decorated with drop downs. Each

217
00:11:42.960 --> 00:11:46.000
choice is stored as plain text or sometimes Jason flavored markup,

218
00:11:46.039 --> 00:11:49.679
depending on column settings. Good luck filtering efficiently data verse

219
00:11:49.679 --> 00:11:53.440
translates options into integer mapped sets for quick comparison. Share

220
00:11:53.440 --> 00:11:56.120
Point just sifts through strings the way a librarian searches

221
00:11:56.120 --> 00:11:58.240
a card catalog in the dark. Then we have the

222
00:11:58.240 --> 00:12:02.840
illusion of normalization. In legitimate database design, normalization prevents redundancy.

223
00:12:03.399 --> 00:12:07.159
Each entity lives exactly once, saving space and ensuring consistency.

224
00:12:07.240 --> 00:12:11.200
Sharepointnds politely and does the opposite. Lists operate in parallel universes.

225
00:12:11.519 --> 00:12:14.600
You can normalize manually split your data into multiple lists

226
00:12:14.639 --> 00:12:18.240
and reference them, but every look up slows performance. Normalize

227
00:12:18.279 --> 00:12:20.440
too much and your power app spends its life resolving

228
00:12:20.480 --> 00:12:24.240
relationships instead of serving users. Denormalized to simplify performance, and

229
00:12:24.240 --> 00:12:27.759
you sacrifice integrity, turning your lists into mutant hybrids full

230
00:12:27.799 --> 00:12:30.279
of duplicated values. It's a loose, lose game designed by

231
00:12:30.279 --> 00:12:32.919
someone who mistook sheet music for a soundtrack. The practical

232
00:12:32.919 --> 00:12:37.080
outcome most power apps running on SharePoint settle into lazy denormalization.

233
00:12:37.440 --> 00:12:40.840
Each list becomes a wide table stuffed with repeating data

234
00:12:40.879 --> 00:12:43.639
just to avoid fetching lookups. It feels efficient until the

235
00:12:43.720 --> 00:12:48.679
data starts drifting. Department names, misspelled users, duplicated references out

236
00:12:48.679 --> 00:12:51.759
of sync. By month three, your database agrees with itself

237
00:12:51.840 --> 00:12:55.279
about as much as conspiracy theorists at a Flat Earth convention.

238
00:12:55.639 --> 00:12:58.240
Power Apps compounds this with its handling of data calls.

239
00:12:58.960 --> 00:13:01.480
Each related record shown in a form is fetched via

240
00:13:01.480 --> 00:13:05.840
a separate query, occasionally catching masks the inefficiency, but open

241
00:13:05.879 --> 00:13:09.879
a deep form with multiple look ups, client, product manager status,

242
00:13:10.159 --> 00:13:12.759
and behind the scenes, SharePoint is juggling a small crowd

243
00:13:12.840 --> 00:13:16.360
of network requests. Any latency along the way multiplies. The

244
00:13:16.399 --> 00:13:19.440
result is that users open a record, wait a few seconds,

245
00:13:19.759 --> 00:13:23.039
then start clicking out of frustration, triggering another round of

246
00:13:23.080 --> 00:13:27.879
premature network chaos. Developers respond with clever but ruinous workarounds, collections,

247
00:13:27.919 --> 00:13:30.399
local caches, manual jason passing all in the name of

248
00:13:30.440 --> 00:13:33.879
pretending relationships behave like secral joints. It works briefly until

249
00:13:33.960 --> 00:13:37.080
update conflicts appear. Someone edits from a mobile version while

250
00:13:37.080 --> 00:13:40.320
another user edits the same record in the browser. SharePoint

251
00:13:40.399 --> 00:13:44.159
doesn't negotiate. It simply overrides. One person wins, the other

252
00:13:44.440 --> 00:13:48.000
loses silently. The system smiles and tells you everything safe correctly.

253
00:13:48.200 --> 00:13:50.879
It didn't imagine running a bank ledger on post it notes.

254
00:13:50.919 --> 00:13:53.919
Each look up column is another sticky label you might misplace.

255
00:13:54.279 --> 00:13:56.480
At small scale, you can keep track. Once the wind

256
00:13:56.480 --> 00:13:59.919
picks up, say, concurrent users bulk updates or automated flows.

257
00:14:00.120 --> 00:14:03.600
The notes scattered. That's SharePoint relationships held together by duct

258
00:14:03.600 --> 00:14:06.639
tape and hope forever one sneeze away from chaos. Even

259
00:14:06.639 --> 00:14:09.440
more deceptive is how friendly it feels. At first. The

260
00:14:09.480 --> 00:14:12.919
interface offers easy linking between lists. You click a drop down,

261
00:14:12.960 --> 00:14:15.639
pick look up from another list, and instantly it seems powerful.

262
00:14:16.039 --> 00:14:19.159
But underneath, no relational matter data exists. Just store text

263
00:14:19.240 --> 00:14:22.519
with a fragile correlation ID, delete or rename the target column,

264
00:14:22.559 --> 00:14:24.960
and you've broken the map. Power apps tries to follow

265
00:14:24.960 --> 00:14:27.600
the trail and falls through a logic hole debugging that

266
00:14:27.679 --> 00:14:31.679
is like tracing spaghetti in a fog. Normalization evangelists eventually

267
00:14:31.679 --> 00:14:37.480
face an existential crisis. They design beautifully structured SharePoint lists, employees, departments, projects,

268
00:14:37.519 --> 00:14:39.919
each with crisp lookups. Then they publish the app and

269
00:14:40.039 --> 00:14:44.360
users complain it's unbearably slow. The architects capitulate, merge lists,

270
00:14:44.639 --> 00:14:48.840
denormalize data, and accept the compromise. SharePoint rewards disorder, punishing

271
00:14:48.840 --> 00:14:52.279
proper design. It's the academic equivalent of a teacher docking points.

272
00:14:52.279 --> 00:14:54.519
For turning in grammar that's too correct by now you

273
00:14:54.559 --> 00:14:57.600
should see the broader point. SharePoint doesn't understand relational theory

274
00:14:57.600 --> 00:15:00.600
because it was never meant to. It's built for story documents,

275
00:15:00.600 --> 00:15:05.080
comments and metadata about those documents, not executing complex relational logic.

276
00:15:05.200 --> 00:15:07.759
The moment you rely on it to maintain relationships, you're

277
00:15:07.799 --> 00:15:11.120
forcing a librarian to perform as a database administrator. It smiles,

278
00:15:11.120 --> 00:15:14.440
pretends to help, then misfiles half your records behind the photocopier,

279
00:15:14.679 --> 00:15:17.840
and yet people remain hopeful. Maybe security makes up for it,

280
00:15:17.879 --> 00:15:21.519
they say, as though item level permissions could save structural design. Spoiler,

281
00:15:21.679 --> 00:15:24.559
they can't. Security may look like order, but when applied

282
00:15:24.559 --> 00:15:27.879
at sharepoints microscopic scale, it becomes another performance traps. So

283
00:15:28.200 --> 00:15:31.039
before you declare victory because our lists have look ups,

284
00:15:31.120 --> 00:15:33.799
pause and check the integrity. If the links break and

285
00:15:33.840 --> 00:15:37.320
nobody notices until the quarterly report, you've built a time bomb, Quiet,

286
00:15:37.440 --> 00:15:40.919
polite and waiting. Next, let's test whether security really redeems

287
00:15:40.960 --> 00:15:43.879
any of this architectural chaos, or if, like the rest,

288
00:15:43.960 --> 00:15:47.639
it's merely another illusion wrapped in a SharePoint smile security

289
00:15:47.840 --> 00:15:51.320
life cycle and tag debt ah. Yes, the comfort blanket

290
00:15:51.360 --> 00:15:55.240
of every SharePoint apologist security. But it has amazing permissions,

291
00:15:55.279 --> 00:15:59.960
they say, technically true, functionally disastrous. SharePoint does, in fact,

292
00:16:00.159 --> 00:16:03.960
let you assign security at almost any level imaginable. Side library,

293
00:16:04.000 --> 00:16:06.120
list item. You can lock down a single row so

294
00:16:06.200 --> 00:16:08.679
tightly that even its creator can't find it again. It's

295
00:16:08.679 --> 00:16:11.720
a marvel of granularity. It's also a nightmare of maintainability.

296
00:16:11.799 --> 00:16:14.399
In a real database like secol or data Verse, security

297
00:16:14.440 --> 00:16:18.720
operates predictably. You define roles reader, contributor admin. Those roles

298
00:16:18.759 --> 00:16:21.080
apply at the table, row, or even column level, depending

299
00:16:21.080 --> 00:16:24.159
on the engine. There's structure, there's logic. The boundaries are

300
00:16:24.240 --> 00:16:29.120
enforced systematically, not emotionally. SharePoint, however, applies security like confetti

301
00:16:29.159 --> 00:16:31.440
at a wedding. It's everywhere, and no one remembers who

302
00:16:31.480 --> 00:16:33.840
threw it. Each time you break inheritance on a list item.

303
00:16:33.879 --> 00:16:37.720
SharePoint creates an independent access control list entry sounds fine

304
00:16:37.759 --> 00:16:41.600
until you have hundreds, ten thousands each demanding separate evaluation

305
00:16:41.679 --> 00:16:44.759
by the permission engine. That's when queries slow down, not

306
00:16:44.840 --> 00:16:47.519
because your data is complex, but because SharePoint is busy

307
00:16:47.519 --> 00:16:51.120
recalculating who's allowed to see which row you wanted granular security,

308
00:16:51.200 --> 00:16:54.759
you got molasses. Picture a librarian checking ID before handing

309
00:16:54.799 --> 00:16:57.960
out every individual page of a book. It's technically secure, yes,

310
00:16:58.240 --> 00:17:01.360
but you'll die of boredom before finishing chapter one. SharePoint

311
00:17:01.399 --> 00:17:04.920
does exactly that. Across your list views. The result performance

312
00:17:04.920 --> 00:17:07.960
collapses proportionally to how secure you tried to make it. True.

313
00:17:08.000 --> 00:17:10.880
Databased platforms handle this with row filtered views and role

314
00:17:10.880 --> 00:17:14.680
based access at query time, one efficient rule set applied dynamically,

315
00:17:15.039 --> 00:17:17.640
SharePoint brute forces it at load time. Genius in a

316
00:17:17.680 --> 00:17:20.359
sort of medieval way. Now add power apps to that equation.

317
00:17:20.480 --> 00:17:23.079
Every time the app opens a gallery, it authenticates through

318
00:17:23.119 --> 00:17:26.160
your context, fires off list queries, and evaluates those permissions

319
00:17:26.200 --> 00:17:29.119
one item at a time. Users think their device is slow,

320
00:17:29.559 --> 00:17:33.559
in reality, it's SharePoint playing bureaucrat, stamping each record approved

321
00:17:33.559 --> 00:17:37.119
for viewing before rendering the screen. Multiply that across hundreds

322
00:17:37.119 --> 00:17:39.599
of users, and the infrastructure wheezes like a fax machine.

323
00:17:39.599 --> 00:17:41.960
In twenty twenty four, this is where most teams start

324
00:17:41.960 --> 00:17:45.680
introducing shortcuts to save themselves. They duplicate data into unsecured

325
00:17:45.720 --> 00:17:49.599
lists for convenience's sake, or create automation that copies save subsets.

326
00:17:49.680 --> 00:17:53.920
Nightly congratulations you've just built shadow databases without integrity constraints,

327
00:17:54.119 --> 00:17:57.200
security becomes a patchwork of wishful thinking and with no

328
00:17:57.319 --> 00:18:00.839
centralized schema or role based system auditing, who can see

329
00:18:00.839 --> 00:18:04.160
what turns into an archaeological dig through broken inheritance chains.

330
00:18:04.200 --> 00:18:06.759
But security is only the first layer of dysfunction. Let's

331
00:18:06.759 --> 00:18:09.319
talk live cycle management, the grown up part of any

332
00:18:09.319 --> 00:18:16.920
software system. In proper database environments, you migrate through environments effortlessly, development, test, production, data,

333
00:18:17.039 --> 00:18:21.319
verse packages tables neatly inside power platform solutions. Esquel exports

334
00:18:21.319 --> 00:18:24.359
its schema in a single script SharePoint. It stares blankly,

335
00:18:24.559 --> 00:18:27.359
mutters something about list templates, and leaves you to figure

336
00:18:27.400 --> 00:18:30.240
out the rest. Moving a SharePoint data model between environments

337
00:18:30.279 --> 00:18:35.279
is like cloning Frankenstein. Theoretically possible, practically horrifying columns, loose types,

338
00:18:35.519 --> 00:18:38.839
choice values, mutate, look up IDs regenerate like chaotic DNA.

339
00:18:39.160 --> 00:18:42.720
Automated provisioning scripts attempt to recreate lists by name, only

340
00:18:42.759 --> 00:18:46.359
to discover that sharepoints internal identifiers don't align across sites.

341
00:18:46.640 --> 00:18:49.039
The resulting environment might look similar on the surface, but

342
00:18:49.200 --> 00:18:53.279
underneath it's a totally different creature stitch together with mismatched

343
00:18:53.319 --> 00:18:55.920
limbs and fragile wiring, and then you hit the content

344
00:18:56.000 --> 00:18:59.759
migration phase, where developers try to copy test data to production.

345
00:19:00.119 --> 00:19:03.680
SharePoint doesn't have true export import parity. Instead, you rely

346
00:19:03.759 --> 00:19:07.200
on Jason templates, PowerShell scripts, or third party tools that

347
00:19:07.319 --> 00:19:10.559
charge per gigabyte of despair. Migrate one thousand items, lose

348
00:19:10.559 --> 00:19:13.039
twenty lookups, and watch your power app crash because half

349
00:19:13.039 --> 00:19:15.880
its relationships now point to non existent records. That's not

350
00:19:15.920 --> 00:19:19.119
a migration, it's a funeral. Even versioning one of SharePoint's

351
00:19:19.160 --> 00:19:23.279
banner features becomes treacherous. The platform dutifully keeps historical copies

352
00:19:23.279 --> 00:19:26.240
of items, but power Apps doesn't integrate meaningfully with that

353
00:19:26.400 --> 00:19:29.119
version history. When something breaks, you can technically roll back,

354
00:19:29.400 --> 00:19:32.440
but you'll lose relational context in the process. Database tracks

355
00:19:32.519 --> 00:19:36.480
changes transactionally, you can restore state coherently. SharePoint just hands

356
00:19:36.519 --> 00:19:39.480
you a random past snapshot and says, good luck reconciling

357
00:19:39.519 --> 00:19:43.039
this mess. The tragedy here is cumulative. Each fragile list,

358
00:19:43.039 --> 00:19:47.240
each manual security rule, each handcrafted migration adds invisible weight.

359
00:19:47.400 --> 00:19:51.039
That's technical debt, the system equivalent of cholesterol. It clogs everything.

360
00:19:51.119 --> 00:19:53.599
Time that should go into improving your app instead goes

361
00:19:53.599 --> 00:19:57.559
into maintaining permission hierarchies and rebuilding lists that fail silently

362
00:19:57.960 --> 00:20:01.160
and the kicker. Most of that debt accruise because of

363
00:20:01.160 --> 00:20:04.680
a single flawed assumption that SharePoint was free, so cutting

364
00:20:04.759 --> 00:20:07.759
corners was justified. The next section rips the bandage of

365
00:20:07.880 --> 00:20:11.720
that illusion. Spoiler alert, the free option always charges interest. Later,

366
00:20:12.319 --> 00:20:15.079
the licensing trap and the free fallacy. Here's the root

367
00:20:15.119 --> 00:20:18.880
of this chaos. Accountants love free. The power platform license

368
00:20:18.920 --> 00:20:22.160
includes SharePoint, so using it feels thrifty. No approvals, no

369
00:20:22.240 --> 00:20:25.880
budget fights until later when the hidden technical debt arrives,

370
00:20:25.920 --> 00:20:29.920
disguised as maintenance, frustration and rebuild costs. Organizations don't pick

371
00:20:29.960 --> 00:20:33.880
SharePoint for capability. They pick it for optics where maximizing investment,

372
00:20:34.000 --> 00:20:37.000
they say, ignoring that those savings vanish once the app grows.

373
00:20:37.559 --> 00:20:40.400
Data verse costs more. Yes, but you're buying delegation, integrity,

374
00:20:40.400 --> 00:20:43.759
proper security, and ilam insurance that works when the fire starts.

375
00:20:44.240 --> 00:20:47.759
SharePoint tempts because it's easy, quick set up, instant demo applause.

376
00:20:48.119 --> 00:20:51.279
Then resources crawls, screens freeze, and it gets blamed. The

377
00:20:51.319 --> 00:20:54.759
saving ends up spent on consultants rebuilding it in data verse.

378
00:20:55.440 --> 00:20:58.640
This pattern repeats constantly free tools lwed teams into expensive

379
00:20:58.680 --> 00:21:03.240
consequences at scale. That false economy burns more hours, wages,

380
00:21:03.279 --> 00:21:06.160
and patients than any data verse license ever. Would you

381
00:21:06.319 --> 00:21:09.519
saved twenty dollars per user? Excellent? That'll cover a fraction

382
00:21:09.559 --> 00:21:12.680
of your next two hundred thousand dollars rebuilt. Microsoft didn't

383
00:21:12.720 --> 00:21:15.160
hide the truth. They built data Verse for scale because

384
00:21:15.200 --> 00:21:20.319
SharePoint never was. Ignoring that boundary isn't innovation, it's negligence.

385
00:21:21.039 --> 00:21:23.960
File cabinets don't run engines. Let's end this with the

386
00:21:24.000 --> 00:21:28.440
matter for everyone remembers. SharePoint is a filing cabinet. Beautifully labeled,

387
00:21:28.599 --> 00:21:34.680
permission controlled, and spacious databases are engines, precisely tuned, pressure tested,

388
00:21:34.720 --> 00:21:38.240
and built for sustained power. One stores the other, computes,

389
00:21:38.319 --> 00:21:40.799
confuse the two, and your power up becomes a car

390
00:21:40.960 --> 00:21:44.680
powered by stationary. Every symptom you've met, slow galleries, broken

391
00:21:44.680 --> 00:21:48.160
look ups, failed migrations stems from that category era. SharePoint

392
00:21:48.200 --> 00:21:51.440
isn't broken, your expectations are. It's not that Microsoft misled you.

393
00:21:51.720 --> 00:21:54.440
It's that you misapplied a product built for collaboration to

394
00:21:54.480 --> 00:21:57.960
a system demanding relational rigor. A filing cabinet can't negotiate

395
00:21:57.960 --> 00:21:59.960
transactions anymore than a stapler can run an a lit

396
00:22:00.680 --> 00:22:03.839
And if you genuinely need scale, concurrency, security, and integrity,

397
00:22:04.039 --> 00:22:06.640
stop living on borrowed code. Move the data to data

398
00:22:06.720 --> 00:22:09.279
Verse or seql where it belongs. Yes, licenses cost money,

399
00:22:09.319 --> 00:22:11.759
so does electricity, gravity, and every other law of physics

400
00:22:11.839 --> 00:22:14.960
your business depends on. So here's the blunt truth. Building

401
00:22:15.000 --> 00:22:17.359
an enterprise great power app on share Point is like

402
00:22:17.400 --> 00:22:20.480
balancing a skyscraper on Jello. It looks fine until someone moves.

403
00:22:20.839 --> 00:22:25.160
Then everything collapses slowly, expensively, and predictably. Don't wait for

404
00:22:25.160 --> 00:22:28.720
your app to become a cautionary screenshot. Migrate now, budget properly,

405
00:22:28.759 --> 00:22:31.680
and treat architecture as non negotiable. If this explanation saved

406
00:22:31.720 --> 00:22:36.119
you a future rebuild, repay the favor, subscribe, tap follow,

407
00:22:36.480 --> 00:22:40.720
enable notifications, and get each new episode delivered like dependable patches,

408
00:22:40.960 --> 00:22:44.160
on time every time. Keep watching, keep optimizing, and stop

409
00:22:44.160 --> 00:22:45.839
mistaking filing cabinets for engines

Mirko Peters

Founder of m365.fm, m365.show and m365con.net

Mirko Peters is a Microsoft 365 expert, content creator, and founder of m365.fm, a platform dedicated to sharing practical insights on modern workplace technologies. His work focuses on Microsoft 365 governance, security, collaboration, and real-world implementation strategies.

Through his podcast and written content, Mirko provides hands-on guidance for IT professionals, architects, and business leaders navigating the complexities of Microsoft 365. He is known for translating complex topics into clear, actionable advice, often highlighting common mistakes and overlooked risks in real-world environments.

With a strong emphasis on community contribution and knowledge sharing, Mirko is actively building a platform that connects experts, shares experiences, and helps organizations get the most out of their Microsoft 365 investments.

Users see wrong data in Power Apps? Here’s why SharePoint fails