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