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
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
