Opening: The False Comfort of “Free Databases”You’ve heard this phrase before—casually dropped into Microsoft Teams calls with frightening confidence—“Oh, we’ll just use SharePoint as the database for our Power App.”And there it is. The modern cry of the overconfident citizen developer.This, right here, is the problem. People hear “data stored somewhere” and immediately conclude “database.” By that logic, your junk drawer is a supply chain management system.The confusion is forgivable, barely. SharePoint does hold data, and Power Apps can read it. But that does not make it a database any more than Excel becomes a server when you save two worksheets.Average users love the illusion. SharePoint lists look structured. They have columns and rows, fields and filters. And of course—it’s already included in Microsoft 365, so it must be good enough, right?Wrong. You’re about to see why the “free” database sitting in your tenant is a performance time bomb disguised as convenience.By the end, you’ll understand why Power Apps that begin with “just SharePoint” eventually die gasping under their own weight—and why treating it like SQL is the digital equivalent of trusting a filing cabinet to run an engine.Section 1: What a Database Actually IsLet’s reset the definitions before your app implodes. A proper database isn’t just a bucket that holds information. It’s a system built on architecture and logic. It has order, schema, indexing, relationships, and concurrency control—the invisible infrastructure that lets dozens or thousands of users read, write, and query your data without tripping over each other.SQL Server and Dataverse handle this beautifully. Schemas define the blueprint—every column type and constraint serves like support beams in a skyscraper. Indexes act as the elevator shafts that get you exactly where you need, fast. Relationships keep records consistent, ensuring that when one table sneezes, its related tables say “bless you” in perfect synchronization.Now compare that to SharePoint. SharePoint was not designed to manage transactions at scale. Its DNA is collaboration, version history, permissions, and file storage. It’s more like a glorified document librarian than a record-keeping accountant. It’s wonderful at organizing text, attachments, and metadata—but call it a database, and you might as well call your filing cabinet a “data processing engine.”Real databases think in joins, referential integrity, and execution plans. SharePoint thinks in lists, permissions, and column choices written by someone who definitely didn’t study relational theory. It’s a web layer optimized for people, not for queries.Here’s where the Power Apps confusion begins. The app happily connects to SharePoint through an OData connector. You can create forms, galleries, and dashboards. On the surface, everything looks professional. The danger is invisible—until your app grows.I once met a department that proudly built their internal CRM entirely on top of four SharePoint lists. It worked beautifully—for a month. Then came the fifth thousand record. Suddenly the app stuttered, screens froze, and every gallery took half a minute to load. Their users thought the problem was “bad Wi‑Fi.” It wasn’t Wi‑Fi. It was physics. SharePoint was trying to impersonate a relational database.The truth? Power Apps can connect to SharePoint, but that’s all it does—connect. It borrows the data source, but it doesn’t make SharePoint any smarter. There’s no hidden engine under the surface waiting to optimize your queries.Imagine trying to race with a car built from bicycle parts. Sure, it has wheels. It moves. But once you hit highway speeds, bolts start flying. The handlebars—the list structure—were never designed to steer that kind of load.Dataverse, in contrast, is a proper engine. It’s transactional, relational, optimized for delegation, and built for Power Platform from the ground up. It follows database logic, not just storage logic. That’s the difference between structured speed and unstructured sprawl.SharePoint has indexing—but limited. It has lookup columns—but no genuine referential constraints. It allows multiple users—but not graceful concurrency handling. You can write to it, but if three users edit the same record at once, one loses. Usually the intern.Essentially, a database enforces integrity while SharePoint hopes for good behavior. SQL refuses to accept invalid relationships. SharePoint accepts everything, smiles politely, and breaks quietly months later.If this still feels theoretical, don’t worry. Scale will make it painfully real. Because while architecture can be ignored for a while, performance cannot. And as your user base grows, your “database” made from friendly SharePoint lists will groan like a spreadsheet with delusions of grandeur.The next part is where the collapse begins: Microsoft’s shiny number—30 million items—and the cruel joke hiding behind it. Let’s talk about scale, the silent killer of every Power App that mistook convenience for capability.Section 2: The Scale MythMicrosoft loves big numbers. Nothing sells confidence like a glossy documentation page claiming your SharePoint list can hold—wait for it—thirty million items. Sounds impressive, doesn’t it? Thirty million entries! You could store the payroll history of an empire. The problem is that the number is marketing, not math. That limit describes what SharePoint can physically contain, not what it can functionally handle. It’s like saying a washing machine can technically fit ten bowling balls. True. Until you press start.In reality, the moment those lists creep beyond a few thousand records, Power Apps begins its slow descent into misery. Buttons take seconds to respond. Galleries forget how to scroll smoothly. You click “Filter,” and the spinning dots start an existential performance art piece. By ten thousand records, it feels like wading through syrup. Beyond that, you’re practically time‑traveling—all the way back to dial‑up.The core culprit here is a polite little concept called delegation. It’s Power Apps’ way of saying, “I can’t handle that query locally, so I’ll ask the data source to compute it for me.” SharePoint, however, isn’t fluent in that language. Its delegation capabilities are minimal. Translation: anything outside a small set of filter and sort operations is pulled locally. The data comes down the wire, record by record, so your client device ends up doing the heavy lifting a real database engine would have done in milliseconds. You built an enterprise app, and now every user’s laptop is its database server. Congratulations.The infamous 2,000‑item delegation wall isn’t a myth—it’s a design constraint. Unless you use creative (and usually fragile) pagination workarounds, Power Apps simply refuses to process more. You can raise that ceiling a little with clever queries, but eventually the data set expands faster than the platform can pretend nothing’s wrong. Even if you index your columns—the supposed magic trick—things only improve marginally. Like upgrading a rubber band with a thicker rubber band.Microsoft’s documentation hints that indexing can let you manage up to around 25,000 records if you’re “careful.” Translation: it will technically work while producing the user experience of a PowerPoint slideshow transmitted over carrier pigeons. The indexes prevent total collapse but can’t change the fact that SharePoint stores data in what is essentially a flattened web table. Each query becomes a request for a giant JSON blob, parsed piece by piece. SQL or Dataverse, by contrast, sends back neat pre‑processed chunks of matching rows. SharePoint just hands you everything and says, “Good luck sorting it.”Every extra thousand records adds latency. It’s not linear—it’s exponential. One thousand rows? Acceptable. Ten thousand? Noticeable lag. Twenty thousand? Every gallery becomes a meditation exercise. Users start clicking twice, thinking their devices froze, which of course triggers double updates and conflicting writes. That’s when someone suggests “maybe we should rebuild this in Excel,” and the circle of bad decisions completes itself.Using SharePoint as a back‑end at scale is like powering a data center with AA batteries. Each small operation works, barely. But time and concurrency amplify the load until the whole thing starts coughing. The connectors try to fetch data while maintaining security context, evaluating filters, and managing throttling—all over cloud HTTP calls that multiply faster than your patience decreases. Meanwhile, Dataverse or SQL would be compressing, caching, and delegating queries natively. SharePoint’s response to that level of complexity? A polite shrug followed by a timeout.And don’t forget throttling. Once you exceed certain thresholds in Office 365, SharePoint starts limiting the number of requests per user per minute. It doesn’t warn you nicely—it simply refuses to serve data for a few seconds. Multiply that delay by hundreds of active users, and you’ve turned your business app into a queue simulator. Remember: throttling isn’t failure; it’s SharePoint’s polite way of begging you to stop abusing it.Now, let’s add relationships into the mix. Many creators think scaling problems vanish if they just break lists apart. “We’ll have one for Customers, one for Orders, one for Products, and link them.” Fascinating optimism. Each lookup between those lists triggers its own set of API calls. So, when you open a single record, you’re actually launching dozens of hidden queries. Multiply that by hundreds of users, and your app starts behaving like a chain smoker climbing stairs. Power Apps will valiantly try to batch requests, but latency stacks faster than performance optimizers can patch it.What’s particularly cruel is how invisible the decay feels at first. Everything seems fine—until the day new data pushes you past that unseen tipping point. Then screens freeze. Connections fail silently. Eventually, developers start layer
Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-podcast–6704921/support.
Follow us on:
LInkedIn
Substack
WEBVTT
1
00:00:00.080 –> 00:00:03.120
You’ve heard this phrase before, casually dropped into Microsoft teams
2
00:00:03.120 –> 00:00:06.759
calls with frightening confidence. Oh, we’ll just use SharePoint as
3
00:00:06.799 –> 00:00:09.160
the database for our power app. And there it is
4
00:00:09.400 –> 00:00:12.199
the modern cry of the over confidence citizen developer. This
5
00:00:12.519 –> 00:00:14.839
right here is the problem. People here at data stored
6
00:00:14.880 –> 00:00:18.719
somewhere and immediately conclude database. By that logic, your junk
7
00:00:18.800 –> 00:00:21.640
draw is a supply chain management system. The confusion is
8
00:00:21.719 –> 00:00:25.239
forgivable barely. SharePoint does hold data and power apps can
9
00:00:25.280 –> 00:00:27.600
read it, but that does not make it a database
10
00:00:27.640 –> 00:00:30.480
anymore than Excel becomes a server when you save two worksheets.
11
00:00:30.559 –> 00:00:33.799
Average users love the illusion. SharePoint lists look structured. They
12
00:00:33.799 –> 00:00:36.640
have columns and rows, fields and filters, and of course
13
00:00:36.679 –> 00:00:39.200
it’s already included in Microsoft three sixty five, so it
14
00:00:39.280 –> 00:00:41.880
must be good enough. Right. Wrong. You’re about to see
15
00:00:41.880 –> 00:00:44.240
why the free database sitting in your tenant is a
16
00:00:44.240 –> 00:00:47.679
performance time bomb disguised as convenience. By the end, you’ll
17
00:00:47.719 –> 00:00:50.960
understand why power apps that begin with just SharePoint eventually
18
00:00:51.000 –> 00:00:53.799
die gasping under their own weight, and why treating it
19
00:00:53.880 –> 00:00:56.479
like sickle is the digital equivalent of trusting a filing
20
00:00:56.520 –> 00:00:59.759
cabinet to run an engine. What a database actually is.
21
00:01:00.079 –> 00:01:03.159
Let’s reset the definitions before your app implodes. A proper
22
00:01:03.240 –> 00:01:05.840
database isn’t just a bucket that holds information. It’s a
23
00:01:05.879 –> 00:01:10.799
system built on architecture and logic. It has order, schema, indexing, relationships,
24
00:01:10.840 –> 00:01:14.439
and concurrency control the invisible infrastructure that leads dozens or
25
00:01:14.480 –> 00:01:17.719
thousands of users read, write, and query your data without
26
00:01:17.760 –> 00:01:20.840
tripping over each other. Sequel server and data verse handle
27
00:01:20.879 –> 00:01:24.280
this beautifully. Skimmers define the blueprint, every column type and
28
00:01:24.359 –> 00:01:27.640
constraint serves like support beams in a skyscraper. Indexes act
29
00:01:27.719 –> 00:01:30.200
as the elevator shafts that get you exactly where you need.
30
00:01:30.400 –> 00:01:34.920
Fast relationships, keep records consistent, ensuring that when one table sneezes,
31
00:01:35.280 –> 00:01:38.840
its related tables say bless you in perfect synchronization. Now
32
00:01:38.879 –> 00:01:41.680
compare that to SharePoint. SharePoint was not designed to manage
33
00:01:41.680 –> 00:01:45.640
transactions at scale. Its DNA is collaboration, version, history, permissions,
34
00:01:45.640 –> 00:01:48.480
and file storage. It’s more like a glorified document librarian
35
00:01:48.519 –> 00:01:51.840
than a record keeping accountant. It’s wonderful at organizing text,
36
00:01:51.840 –> 00:01:54.760
attachments and metadata. But call it a database and you
37
00:01:54.840 –> 00:01:57.840
might as well call your filing cabinet a data processing engine.
38
00:01:58.120 –> 00:02:01.879
Real databases think in joints, rev rntial integrity and execution plans.
39
00:02:02.040 –> 00:02:05.439
SharePoint thinks in lists, permissions, and column choices written by
40
00:02:05.480 –> 00:02:08.599
someone who definitely didn’t study relational theory. It’s a web
41
00:02:08.680 –> 00:02:11.520
layer optimized for people, not for queries. Here’s where the
42
00:02:11.520 –> 00:02:15.039
power apps confusion begins. The app happily connects to SharePoint
43
00:02:15.039 –> 00:02:18.080
through an data connector. You can create forms, galleries, and dashboards.
44
00:02:18.120 –> 00:02:21.120
On the surface, everything looks professional. The danger is invisible
45
00:02:21.319 –> 00:02:23.800
until your app grows. I once met a department that
46
00:02:23.919 –> 00:02:26.800
proudly built their internal CRM entirely on top of four
47
00:02:26.800 –> 00:02:30.039
SharePoint lists. It worked beautifully for a month, then came
48
00:02:30.039 –> 00:02:33.719
the fifth thousand record. Suddenly the apps stuttered, screens froze,
49
00:02:33.719 –> 00:02:36.240
and every gallery took half a minute to load. Their
50
00:02:36.319 –> 00:02:39.360
users thought the problem was bad Wi Fi. It wasn’t
51
00:02:39.400 –> 00:02:42.280
Wi fi, it was physics. SharePoint was trying to impersonate
52
00:02:42.280 –> 00:02:46.000
a relational database. The truth. Power apps can connect to SharePoint,
53
00:02:46.000 –> 00:02:48.439
but that’s all it does. Connect. It borrows the data source,
54
00:02:48.479 –> 00:02:51.039
but it doesn’t make SharePoint any smarter. There’s no hidden
55
00:02:51.039 –> 00:02:54.199
engine under the surface waiting to optimize your queries. Imagine
56
00:02:54.199 –> 00:02:56.400
trying to raise with a car built from bicycle parts.
57
00:02:56.479 –> 00:02:58.919
Sure it has wheels, it moves, but once you hit
58
00:02:59.000 –> 00:03:02.879
highway speeds, bolts start flying the handlebars. The list structure
59
00:03:03.159 –> 00:03:06.000
where never designed to steer that kind of load. Data Verse,
60
00:03:06.120 –> 00:03:09.759
in contrast, is a proper engine. Its transactional, relational, optimized
61
00:03:09.759 –> 00:03:12.719
for delegation and built for power platform from the ground up.
62
00:03:12.840 –> 00:03:16.199
It follows database logic, not just storage logic. That’s the
63
00:03:16.240 –> 00:03:20.319
difference between structured speed and unstructured sprawl. SharePoint has indexing,
64
00:03:20.439 –> 00:03:23.360
but limited. It has look up columns, but no genuine
65
00:03:23.400 –> 00:03:27.960
referential constraints. It allows multiple users, but not graceful concurrency handling.
66
00:03:28.439 –> 00:03:30.280
You can write to it, but if three users added
67
00:03:30.319 –> 00:03:35.159
the same record at once, one loses usually the intern Essentially,
68
00:03:35.280 –> 00:03:39.039
a database enforces integrity. While SharePoint hopes for good behavior,
69
00:03:39.159 –> 00:03:44.000
Circle refuses to accept invalid relationships. SharePoint accepts everything, smiles politely,
70
00:03:44.199 –> 00:03:47.520
and breaks quietly. Months later. If this still feels theoretical,
71
00:03:47.560 –> 00:03:50.400
don’t worry. Scale will make it painfully real, because while
72
00:03:50.479 –> 00:03:53.159
architecture can be ignored for a while, performance cannot, and
73
00:03:53.199 –> 00:03:56.080
as your user base grows, your database made from friendly
74
00:03:56.120 –> 00:03:59.840
SharePoint lists will groan like a spreadsheet with delusions of grandeur.
75
00:04:00.400 –> 00:04:03.560
The next part is where the collapse begins. Microsoft’s shiny
76
00:04:03.639 –> 00:04:07.000
number thirty million items and the cruel joke hiding behind it.
77
00:04:07.159 –> 00:04:09.919
Let’s talk about scale, the silent killer of every power
78
00:04:09.960 –> 00:04:14.039
app that mistook convenience for capability, the scale myth. Microsoft
79
00:04:14.120 –> 00:04:17.839
loves big numbers. Nothing sells confidence like a glossy documentation
80
00:04:17.959 –> 00:04:20.879
page claiming your share Point list can hold wait for it,
81
00:04:20.959 –> 00:04:24.279
thirty million items sounds impressive, doesn’t it. Thirty million entries
82
00:04:24.519 –> 00:04:26.480
you could store the payroll history of an empire. But
83
00:04:26.519 –> 00:04:29.000
the problem is that the number is marketing, not math.
84
00:04:29.279 –> 00:04:32.600
That limit describes what share Point can physically contain, not
85
00:04:32.720 –> 00:04:35.839
what it can functionally handle. It’s like saying a washing
86
00:04:35.879 –> 00:04:39.319
machine can technically fit ten bowling balls. True until you
87
00:04:39.360 –> 00:04:42.160
press start. In reality, the moment those lists creep beyond
88
00:04:42.160 –> 00:04:45.199
a few thousand records, power apps begins its slow descent
89
00:04:45.240 –> 00:04:48.680
into misery. Buttons take seconds to respond. Galleries forget how
90
00:04:48.720 –> 00:04:51.600
to scroll smoothly. You click filter and the spinning dots
91
00:04:51.600 –> 00:04:54.879
start an existential performance art piece by ten thousand records.
92
00:04:54.879 –> 00:04:57.800
It feels like wading through syrup. Beyond that, you’re practically
93
00:04:57.800 –> 00:05:00.560
time traveling all the way back to dial up. The
94
00:05:00.600 –> 00:05:03.399
core culprit here is a polite little concept called delegation.
95
00:05:03.519 –> 00:05:06.079
It’s power App’s way of saying, I can’t handle that
96
00:05:06.160 –> 00:05:08.680
query locally, so I’ll ask the data source to compute
97
00:05:08.720 –> 00:05:11.959
it for me. SharePoint, however, isn’t fluent in that language.
98
00:05:12.079 –> 00:05:15.839
Its delegation capabilities are minimal. Translation anything outside a small
99
00:05:15.839 –> 00:05:18.600
set of filter and sought operations is pulled locally. The
100
00:05:18.680 –> 00:05:20.959
data comes down the wire record by records, so your
101
00:05:20.959 –> 00:05:23.199
client device ends up doing the heavy lifting a real
102
00:05:23.279 –> 00:05:26.040
database engine would have done in milliseconds. You built an
103
00:05:26.160 –> 00:05:30.399
enterprise app, and now every user’s laptop is its database server. Congratulations.
104
00:05:31.759 –> 00:05:34.519
The infamous two thousand item delegation wall isn’t a myth.
105
00:05:34.600 –> 00:05:38.040
It’s a design constraint. Unless you use creative and usually
106
00:05:38.079 –> 00:05:42.360
fragile pagination workarounds, power App simply refuses to process more.
107
00:05:42.480 –> 00:05:44.639
You can raise that ceiling a little with clever queries,
108
00:05:44.839 –> 00:05:47.600
but eventually the data set expands faster than the platform
109
00:05:47.600 –> 00:05:50.240
can pretend nothing’s wrong. Even if you index your columns
110
00:05:50.279 –> 00:05:53.879
the supposed magic trick, things only improve marginally, like upgrading
111
00:05:53.920 –> 00:05:57.040
a rubber band with a thicker rubber band. Microsoft’s documentation
112
00:05:57.160 –> 00:05:59.240
hints that indexing can let you manage up to around
113
00:05:59.240 –> 00:06:02.920
twenty five thousand records if you’re careful. Translation it will
114
00:06:02.920 –> 00:06:06.240
technically work while producing the user experience of a PowerPoint
115
00:06:06.240 –> 00:06:10.160
slide show transmitted over carrier pigeons. The indexes prevent total collapse,
116
00:06:10.199 –> 00:06:12.639
but can’t change the fact that SharePoint stores data in
117
00:06:12.680 –> 00:06:15.680
what is essentially a flattened web table. Each query becomes
118
00:06:15.720 –> 00:06:18.600
a request for a giant Jason blob passed piece by piece,
119
00:06:19.000 –> 00:06:21.959
squirrel or data verse by contrast sends back neat pre
120
00:06:22.000 –> 00:06:25.120
processed chunks of matching rows. SharePoint just hands you everything
121
00:06:25.120 –> 00:06:28.040
and says good luck sorting it. Every extra thousand records
122
00:06:28.079 –> 00:06:32.639
adds latency. It’s not linear, it’s exponential. One thousand rows acceptable,
123
00:06:33.120 –> 00:06:36.439
ten thousand noticeable lag twenty thousand. Every gallery becomes a
124
00:06:36.480 –> 00:06:40.399
meditation exercise. Users start clicking twice, thinking their devices froze,
125
00:06:40.399 –> 00:06:43.399
which of course triggers double updates and conflicting rights. That’s
126
00:06:43.439 –> 00:06:46.360
when someone suggests, maybe we should rebuild this in Excel,
127
00:06:46.879 –> 00:06:50.160
and the circle of bad decisions completes itself. Using SharePoint
128
00:06:50.160 –> 00:06:51.879
as a back end at scale is like powering a
129
00:06:51.959 –> 00:06:55.560
data center with AA batteries. Each small operation works barely,
130
00:06:55.839 –> 00:06:58.399
but time and concurrency amplify the load until the whole
131
00:06:58.399 –> 00:07:01.240
thing starts coughing the connect Try to fetch data while
132
00:07:01.279 –> 00:07:05.120
maintaining security, context, evaluating filters, and managing throttling all over
133
00:07:05.199 –> 00:07:09.560
cloud http calls that multiply faster than your patients decreases. Meanwhile,
134
00:07:09.680 –> 00:07:13.240
Data Verse or SQUAL would be compressing, caching, and delegating
135
00:07:13.279 –> 00:07:16.720
queries Natively. Share Points response to that level of complexity
136
00:07:16.879 –> 00:07:19.360
a polite shrug followed by a timeout, and don’t forget
137
00:07:19.360 –> 00:07:22.519
throttling once you exceed certain thresholds. In Office three sixty five,
138
00:07:22.600 –> 00:07:25.920
Sharepoints starts limiting the number of requests per user per minute.
139
00:07:26.079 –> 00:07:28.800
It doesn’t warn you nicely, it simply refuses to serve
140
00:07:28.879 –> 00:07:31.920
data for a few seconds. Multiply that delay by hundreds
141
00:07:31.920 –> 00:07:34.560
of active users, and you’ve turned your business app into
142
00:07:34.560 –> 00:07:38.560
a queue simulator. Remember, throttling isn’t failure. It’s share points
143
00:07:38.560 –> 00:07:40.879
polite way of begging you to stop abusing it. Now,
144
00:07:40.959 –> 00:07:44.079
let’s add relationships into the mix. Many creators think scaling
145
00:07:44.079 –> 00:07:46.759
problems vanish if they just break lists apart. We’ll have
146
00:07:46.800 –> 00:07:49.399
one for customers, one for orders, one for products and
147
00:07:49.480 –> 00:07:53.040
link them fascinating optimism. Each look up between those lists
148
00:07:53.199 –> 00:07:56.519
triggers its own set of API calls, So when you
149
00:07:56.560 –> 00:07:59.680
open a single record, you’re actually launching dozens of hidden queries.
150
00:08:00.040 –> 00:08:02.639
Apply that by hundreds of users, and your app starts
151
00:08:02.639 –> 00:08:06.240
behaving like a chainsmoker climbing stairs. Power apps will valiantly
152
00:08:06.319 –> 00:08:09.199
try to batch requests, but latency stacks faster than performance
153
00:08:09.199 –> 00:08:12.680
optimizers can patch it. What’s particularly cruel is how invisible
154
00:08:12.680 –> 00:08:16.000
the decay feels. At first. Everything seems fine until the
155
00:08:16.079 –> 00:08:18.959
day new data pushes you past that unseen tipping point.
156
00:08:19.240 –> 00:08:25.040
Then screens freeze, connections fail silently. Eventually, developers start layering
157
00:08:25.079 –> 00:08:29.000
patchwork fixes, smaller galleries, manual catching, collection tricks to load
158
00:08:29.040 –> 00:08:32.240
subsets of data. It looks like progress, but only delays
159
00:08:32.279 –> 00:08:34.679
the inevitable. It’s like rearranging deck chairs on a server
160
00:08:34.759 –> 00:08:38.200
farm that’s on fire. People mistake reliability for survival time.
161
00:08:39.000 –> 00:08:42.600
It’s worked for months, they say, proudly, ignoring the trend line.
162
00:08:42.679 –> 00:08:46.799
A proper database scales predictably. More data means slightly more storage,
163
00:08:47.000 –> 00:08:51.639
not exponentially slower queries, SharePoint scales emotionally. It starts healthy.
164
00:08:51.840 –> 00:08:54.240
Then suddenly collapses like it just remembered it’s a web
165
00:08:54.279 –> 00:08:57.559
service from two thousand and three, and yet the illusion persists.
166
00:08:57.600 –> 00:09:01.480
Because Microsoft includes SharePoint in the license, the tool is approachable,
167
00:09:01.519 –> 00:09:04.279
the set up effortless, and the first prototype thrillingly quick,
168
00:09:04.480 –> 00:09:10.200
but free convenience hides catastrophic economics. Each delay compounds across users, departments,
169
00:09:10.200 –> 00:09:14.440
and workflows until productivity losses dwarf any licensing savings. The
170
00:09:14.480 –> 00:09:17.879
irony the organization eventually pays far more for an included
171
00:09:17.919 –> 00:09:19.919
feature than it would have for data versus so called
172
00:09:19.960 –> 00:09:23.600
premium price. You wanted relational joints across lists fascinating, Do
173
00:09:23.639 –> 00:09:26.639
you also expect teleportation because that’s about as plausible Inside
174
00:09:26.679 –> 00:09:30.600
Sharepoints architecture, the list interface wasn’t built for transactional queries
175
00:09:30.679 –> 00:09:33.960
or complex aggregation. It’s a collaborative document store that’s being
176
00:09:34.000 –> 00:09:37.360
forced daily to impersonate a relational database. No wonder it
177
00:09:37.399 –> 00:09:40.120
looks tired. So the next time someone quotes that thirty
178
00:09:40.159 –> 00:09:43.200
million item limit, pause, ask them how many they’ve actually
179
00:09:43.279 –> 00:09:46.840
queried successfully in power apps without freezing the app. The
180
00:09:46.919 –> 00:09:49.679
number will be much smaller, somewhere between few thousand and
181
00:09:49.720 –> 00:09:52.919
Please don’t ask. That’s not scale. That’s tolerance, and tolerance
182
00:09:52.960 –> 00:09:55.360
runs out. What follows it is the crash every power
183
00:09:55.360 –> 00:09:58.799
app team eventually experiences the day their free database becomes
184
00:09:58.799 –> 00:10:01.799
a very expensive bottlenet. The visible slowdown is just the start.
185
00:10:01.960 –> 00:10:04.279
What comes next is subtler, the kind of corruption hidden
186
00:10:04.279 –> 00:10:07.080
behind seemingly normal forms and look ups. Because while performance
187
00:10:07.120 –> 00:10:10.240
pain screams, integrity failure whispers, and in the next section
188
00:10:10.279 –> 00:10:14.600
those whispers turn into full blown data chaos, relationships, look ups,
189
00:10:14.679 –> 00:10:17.639
and other dangerous illusions. Now we reach the part where
190
00:10:17.759 –> 00:10:21.240
SharePoint proudly pretends to be relational. It waives its little
191
00:10:21.240 –> 00:10:24.519
look up column and declares, c I can do relationships too. No,
192
00:10:24.639 –> 00:10:27.039
you can’t, not the kind that mattered, Not the kind
193
00:10:27.080 –> 00:10:31.639
with referential integrity, cascading updates, and proper foreign keys. What
194
00:10:31.720 –> 00:10:34.399
SharePoint offers is a child’s drawing of a database scribbled
195
00:10:34.399 –> 00:10:37.519
in crayon, queued from a far horrifying up close in
196
00:10:37.559 –> 00:10:40.759
a real database. Relationships are contracts. Table A promises to
197
00:10:40.799 –> 00:10:43.240
link only to valid records in table B. If you
198
00:10:43.320 –> 00:10:46.559
delete something in B, the database enforces. What happens next
199
00:10:46.679 –> 00:10:50.480
either block it, cascaded, or update accordingly. Integrity is law.
200
00:10:51.039 –> 00:10:55.480
Share Point by contrast, treats relationships as gossip. I heard
201
00:10:55.519 –> 00:10:58.279
record X, might know record why, but who can say really?
202
00:10:58.759 –> 00:11:01.000
Delete the parent list item and the child keeps an
203
00:11:01.080 –> 00:11:03.960
orphaned reference quietly rotting until a user clicks it and
204
00:11:04.000 –> 00:11:06.600
gets an error that looks like a riddle. Developers cling
205
00:11:06.679 –> 00:11:09.960
to look up columns thinking they’re safe, and they’re not relationships.
206
00:11:09.960 –> 00:11:12.399
They’re lightweight pointers that store the ID and a bit
207
00:11:12.440 –> 00:11:15.639
of display text, nothing more. They don’t validate consistency, they
208
00:11:15.639 –> 00:11:18.720
don’t prevent duplicates. They simply assume nothing will go wrong,
209
00:11:18.759 –> 00:11:21.720
which is adorable. And when power apps uses those lookups,
210
00:11:21.759 –> 00:11:24.600
it has to perform multiple calls, one to retrieve the
211
00:11:24.639 –> 00:11:27.600
main list, another to resolve each look up. That’s dozens
212
00:11:27.600 –> 00:11:30.080
of round trips just to reconstruct what cycle would fetch
213
00:11:30.120 –> 00:11:33.240
in one joint. Every lookup adds lag, every nested gallery
214
00:11:33.279 –> 00:11:36.039
doubles it. Choice columns are equally misleading. They look like
215
00:11:36.120 –> 00:11:39.440
constraint enforcement preset options, clean new eye, but under the
216
00:11:39.480 –> 00:11:42.879
hood their glorified text fields decorated with drop downs. Each
217
00:11:42.960 –> 00:11:46.000
choice is stored as plain text or sometimes Jason flavored markup,
218
00:11:46.039 –> 00:11:49.679
depending on column settings. Good luck filtering efficiently data verse
219
00:11:49.679 –> 00:11:53.440
translates options into integer mapped sets for quick comparison. Share
220
00:11:53.440 –> 00:11:56.120
Point just sifts through strings the way a librarian searches
221
00:11:56.120 –> 00:11:58.240
a card catalog in the dark. Then we have the
222
00:11:58.240 –> 00:12:02.840
illusion of normalization. In legitimate database design, normalization prevents redundancy.
223
00:12:03.399 –> 00:12:07.159
Each entity lives exactly once, saving space and ensuring consistency.
224
00:12:07.240 –> 00:12:11.200
Sharepointnds politely and does the opposite. Lists operate in parallel universes.
225
00:12:11.519 –> 00:12:14.600
You can normalize manually split your data into multiple lists
226
00:12:14.639 –> 00:12:18.240
and reference them, but every look up slows performance. Normalize
227
00:12:18.279 –> 00:12:20.440
too much and your power app spends its life resolving
228
00:12:20.480 –> 00:12:24.240
relationships instead of serving users. Denormalized to simplify performance, and
229
00:12:24.240 –> 00:12:27.759
you sacrifice integrity, turning your lists into mutant hybrids full
230
00:12:27.799 –> 00:12:30.279
of duplicated values. It’s a loose, lose game designed by
231
00:12:30.279 –> 00:12:32.919
someone who mistook sheet music for a soundtrack. The practical
232
00:12:32.919 –> 00:12:37.080
outcome most power apps running on SharePoint settle into lazy denormalization.
233
00:12:37.440 –> 00:12:40.840
Each list becomes a wide table stuffed with repeating data
234
00:12:40.879 –> 00:12:43.639
just to avoid fetching lookups. It feels efficient until the
235
00:12:43.720 –> 00:12:48.679
data starts drifting. Department names, misspelled users, duplicated references out
236
00:12:48.679 –> 00:12:51.759
of sync. By month three, your database agrees with itself
237
00:12:51.840 –> 00:12:55.279
about as much as conspiracy theorists at a Flat Earth convention.
238
00:12:55.639 –> 00:12:58.240
Power Apps compounds this with its handling of data calls.
239
00:12:58.960 –> 00:13:01.480
Each related record shown in a form is fetched via
240
00:13:01.480 –> 00:13:05.840
a separate query, occasionally catching masks the inefficiency, but open
241
00:13:05.879 –> 00:13:09.879
a deep form with multiple look ups, client, product manager status,
242
00:13:10.159 –> 00:13:12.759
and behind the scenes, SharePoint is juggling a small crowd
243
00:13:12.840 –> 00:13:16.360
of network requests. Any latency along the way multiplies. The
244
00:13:16.399 –> 00:13:19.440
result is that users open a record, wait a few seconds,
245
00:13:19.759 –> 00:13:23.039
then start clicking out of frustration, triggering another round of
246
00:13:23.080 –> 00:13:27.879
premature network chaos. Developers respond with clever but ruinous workarounds, collections,
247
00:13:27.919 –> 00:13:30.399
local caches, manual jason passing all in the name of
248
00:13:30.440 –> 00:13:33.879
pretending relationships behave like secral joints. It works briefly until
249
00:13:33.960 –> 00:13:37.080
update conflicts appear. Someone edits from a mobile version while
250
00:13:37.080 –> 00:13:40.320
another user edits the same record in the browser. SharePoint
251
00:13:40.399 –> 00:13:44.159
doesn’t negotiate. It simply overrides. One person wins, the other
252
00:13:44.440 –> 00:13:48.000
loses silently. The system smiles and tells you everything safe correctly.
253
00:13:48.200 –> 00:13:50.879
It didn’t imagine running a bank ledger on post it notes.
254
00:13:50.919 –> 00:13:53.919
Each look up column is another sticky label you might misplace.
255
00:13:54.279 –> 00:13:56.480
At small scale, you can keep track. Once the wind
256
00:13:56.480 –> 00:13:59.919
picks up, say, concurrent users bulk updates or automated flows.
257
00:14:00.120 –> 00:14:03.600
The notes scattered. That’s SharePoint relationships held together by duct
258
00:14:03.600 –> 00:14:06.639
tape and hope forever one sneeze away from chaos. Even
259
00:14:06.639 –> 00:14:09.440
more deceptive is how friendly it feels. At first. The
260
00:14:09.480 –> 00:14:12.919
interface offers easy linking between lists. You click a drop down,
261
00:14:12.960 –> 00:14:15.639
pick look up from another list, and instantly it seems powerful.
262
00:14:16.039 –> 00:14:19.159
But underneath, no relational matter data exists. Just store text
263
00:14:19.240 –> 00:14:22.519
with a fragile correlation ID, delete or rename the target column,
264
00:14:22.559 –> 00:14:24.960
and you’ve broken the map. Power apps tries to follow
265
00:14:24.960 –> 00:14:27.600
the trail and falls through a logic hole debugging that
266
00:14:27.679 –> 00:14:31.679
is like tracing spaghetti in a fog. Normalization evangelists eventually
267
00:14:31.679 –> 00:14:37.480
face an existential crisis. They design beautifully structured SharePoint lists, employees, departments, projects,
268
00:14:37.519 –> 00:14:39.919
each with crisp lookups. Then they publish the app and
269
00:14:40.039 –> 00:14:44.360
users complain it’s unbearably slow. The architects capitulate, merge lists,
270
00:14:44.639 –> 00:14:48.840
denormalize data, and accept the compromise. SharePoint rewards disorder, punishing
271
00:14:48.840 –> 00:14:52.279
proper design. It’s the academic equivalent of a teacher docking points.
272
00:14:52.279 –> 00:14:54.519
For turning in grammar that’s too correct by now you
273
00:14:54.559 –> 00:14:57.600
should see the broader point. SharePoint doesn’t understand relational theory
274
00:14:57.600 –> 00:15:00.600
because it was never meant to. It’s built for story documents,
275
00:15:00.600 –> 00:15:05.080
comments and metadata about those documents, not executing complex relational logic.
276
00:15:05.200 –> 00:15:07.759
The moment you rely on it to maintain relationships, you’re
277
00:15:07.799 –> 00:15:11.120
forcing a librarian to perform as a database administrator. It smiles,
278
00:15:11.120 –> 00:15:14.440
pretends to help, then misfiles half your records behind the photocopier,
279
00:15:14.679 –> 00:15:17.840
and yet people remain hopeful. Maybe security makes up for it,
280
00:15:17.879 –> 00:15:21.519
they say, as though item level permissions could save structural design. Spoiler,
281
00:15:21.679 –> 00:15:24.559
they can’t. Security may look like order, but when applied
282
00:15:24.559 –> 00:15:27.879
at sharepoints microscopic scale, it becomes another performance traps. So
283
00:15:28.200 –> 00:15:31.039
before you declare victory because our lists have look ups,
284
00:15:31.120 –> 00:15:33.799
pause and check the integrity. If the links break and
285
00:15:33.840 –> 00:15:37.320
nobody notices until the quarterly report, you’ve built a time bomb, Quiet,
286
00:15:37.440 –> 00:15:40.919
polite and waiting. Next, let’s test whether security really redeems
287
00:15:40.960 –> 00:15:43.879
any of this architectural chaos, or if, like the rest,
288
00:15:43.960 –> 00:15:47.639
it’s merely another illusion wrapped in a SharePoint smile security
289
00:15:47.840 –> 00:15:51.320
life cycle and tag debt ah. Yes, the comfort blanket
290
00:15:51.360 –> 00:15:55.240
of every SharePoint apologist security. But it has amazing permissions,
291
00:15:55.279 –> 00:15:59.960
they say, technically true, functionally disastrous. SharePoint does, in fact,
292
00:16:00.159 –> 00:16:03.960
let you assign security at almost any level imaginable. Side library,
293
00:16:04.000 –> 00:16:06.120
list item. You can lock down a single row so
294
00:16:06.200 –> 00:16:08.679
tightly that even its creator can’t find it again. It’s
295
00:16:08.679 –> 00:16:11.720
a marvel of granularity. It’s also a nightmare of maintainability.
296
00:16:11.799 –> 00:16:14.399
In a real database like secol or data Verse, security
297
00:16:14.440 –> 00:16:18.720
operates predictably. You define roles reader, contributor admin. Those roles
298
00:16:18.759 –> 00:16:21.080
apply at the table, row, or even column level, depending
299
00:16:21.080 –> 00:16:24.159
on the engine. There’s structure, there’s logic. The boundaries are
300
00:16:24.240 –> 00:16:29.120
enforced systematically, not emotionally. SharePoint, however, applies security like confetti
301
00:16:29.159 –> 00:16:31.440
at a wedding. It’s everywhere, and no one remembers who
302
00:16:31.480 –> 00:16:33.840
threw it. Each time you break inheritance on a list item.
303
00:16:33.879 –> 00:16:37.720
SharePoint creates an independent access control list entry sounds fine
304
00:16:37.759 –> 00:16:41.600
until you have hundreds, ten thousands each demanding separate evaluation
305
00:16:41.679 –> 00:16:44.759
by the permission engine. That’s when queries slow down, not
306
00:16:44.840 –> 00:16:47.519
because your data is complex, but because SharePoint is busy
307
00:16:47.519 –> 00:16:51.120
recalculating who’s allowed to see which row you wanted granular security,
308
00:16:51.200 –> 00:16:54.759
you got molasses. Picture a librarian checking ID before handing
309
00:16:54.799 –> 00:16:57.960
out every individual page of a book. It’s technically secure, yes,
310
00:16:58.240 –> 00:17:01.360
but you’ll die of boredom before finishing chapter one. SharePoint
311
00:17:01.399 –> 00:17:04.920
does exactly that. Across your list views. The result performance
312
00:17:04.920 –> 00:17:07.960
collapses proportionally to how secure you tried to make it. True.
313
00:17:08.000 –> 00:17:10.880
Databased platforms handle this with row filtered views and role
314
00:17:10.880 –> 00:17:14.680
based access at query time, one efficient rule set applied dynamically,
315
00:17:15.039 –> 00:17:17.640
SharePoint brute forces it at load time. Genius in a
316
00:17:17.680 –> 00:17:20.359
sort of medieval way. Now add power apps to that equation.
317
00:17:20.480 –> 00:17:23.079
Every time the app opens a gallery, it authenticates through
318
00:17:23.119 –> 00:17:26.160
your context, fires off list queries, and evaluates those permissions
319
00:17:26.200 –> 00:17:29.119
one item at a time. Users think their device is slow,
320
00:17:29.559 –> 00:17:33.559
in reality, it’s SharePoint playing bureaucrat, stamping each record approved
321
00:17:33.559 –> 00:17:37.119
for viewing before rendering the screen. Multiply that across hundreds
322
00:17:37.119 –> 00:17:39.599
of users, and the infrastructure wheezes like a fax machine.
323
00:17:39.599 –> 00:17:41.960
In twenty twenty four, this is where most teams start
324
00:17:41.960 –> 00:17:45.680
introducing shortcuts to save themselves. They duplicate data into unsecured
325
00:17:45.720 –> 00:17:49.599
lists for convenience’s sake, or create automation that copies save subsets.
326
00:17:49.680 –> 00:17:53.920
Nightly congratulations you’ve just built shadow databases without integrity constraints,
327
00:17:54.119 –> 00:17:57.200
security becomes a patchwork of wishful thinking and with no
328
00:17:57.319 –> 00:18:00.839
centralized schema or role based system auditing, who can see
329
00:18:00.839 –> 00:18:04.160
what turns into an archaeological dig through broken inheritance chains.
330
00:18:04.200 –> 00:18:06.759
But security is only the first layer of dysfunction. Let’s
331
00:18:06.759 –> 00:18:09.319
talk live cycle management, the grown up part of any
332
00:18:09.319 –> 00:18:16.920
software system. In proper database environments, you migrate through environments effortlessly, development, test, production, data,
333
00:18:17.039 –> 00:18:21.319
verse packages tables neatly inside power platform solutions. Esquel exports
334
00:18:21.319 –> 00:18:24.359
its schema in a single script SharePoint. It stares blankly,
335
00:18:24.559 –> 00:18:27.359
mutters something about list templates, and leaves you to figure
336
00:18:27.400 –> 00:18:30.240
out the rest. Moving a SharePoint data model between environments
337
00:18:30.279 –> 00:18:35.279
is like cloning Frankenstein. Theoretically possible, practically horrifying columns, loose types,
338
00:18:35.519 –> 00:18:38.839
choice values, mutate, look up IDs regenerate like chaotic DNA.
339
00:18:39.160 –> 00:18:42.720
Automated provisioning scripts attempt to recreate lists by name, only
340
00:18:42.759 –> 00:18:46.359
to discover that sharepoints internal identifiers don’t align across sites.
341
00:18:46.640 –> 00:18:49.039
The resulting environment might look similar on the surface, but
342
00:18:49.200 –> 00:18:53.279
underneath it’s a totally different creature stitch together with mismatched
343
00:18:53.319 –> 00:18:55.920
limbs and fragile wiring, and then you hit the content
344
00:18:56.000 –> 00:18:59.759
migration phase, where developers try to copy test data to production.
345
00:19:00.119 –> 00:19:03.680
SharePoint doesn’t have true export import parity. Instead, you rely
346
00:19:03.759 –> 00:19:07.200
on Jason templates, PowerShell scripts, or third party tools that
347
00:19:07.319 –> 00:19:10.559
charge per gigabyte of despair. Migrate one thousand items, lose
348
00:19:10.559 –> 00:19:13.039
twenty lookups, and watch your power app crash because half
349
00:19:13.039 –> 00:19:15.880
its relationships now point to non existent records. That’s not
350
00:19:15.920 –> 00:19:19.119
a migration, it’s a funeral. Even versioning one of SharePoint’s
351
00:19:19.160 –> 00:19:23.279
banner features becomes treacherous. The platform dutifully keeps historical copies
352
00:19:23.279 –> 00:19:26.240
of items, but power Apps doesn’t integrate meaningfully with that
353
00:19:26.400 –> 00:19:29.119
version history. When something breaks, you can technically roll back,
354
00:19:29.400 –> 00:19:32.440
but you’ll lose relational context in the process. Database tracks
355
00:19:32.519 –> 00:19:36.480
changes transactionally, you can restore state coherently. SharePoint just hands
356
00:19:36.519 –> 00:19:39.480
you a random past snapshot and says, good luck reconciling
357
00:19:39.519 –> 00:19:43.039
this mess. The tragedy here is cumulative. Each fragile list,
358
00:19:43.039 –> 00:19:47.240
each manual security rule, each handcrafted migration adds invisible weight.
359
00:19:47.400 –> 00:19:51.039
That’s technical debt, the system equivalent of cholesterol. It clogs everything.
360
00:19:51.119 –> 00:19:53.599
Time that should go into improving your app instead goes
361
00:19:53.599 –> 00:19:57.559
into maintaining permission hierarchies and rebuilding lists that fail silently
362
00:19:57.960 –> 00:20:01.160
and the kicker. Most of that debt accruise because of
363
00:20:01.160 –> 00:20:04.680
a single flawed assumption that SharePoint was free, so cutting
364
00:20:04.759 –> 00:20:07.759
corners was justified. The next section rips the bandage of
365
00:20:07.880 –> 00:20:11.720
that illusion. Spoiler alert, the free option always charges interest. Later,
366
00:20:12.319 –> 00:20:15.079
the licensing trap and the free fallacy. Here’s the root
367
00:20:15.119 –> 00:20:18.880
of this chaos. Accountants love free. The power platform license
368
00:20:18.920 –> 00:20:22.160
includes SharePoint, so using it feels thrifty. No approvals, no
369
00:20:22.240 –> 00:20:25.880
budget fights until later when the hidden technical debt arrives,
370
00:20:25.920 –> 00:20:29.920
disguised as maintenance, frustration and rebuild costs. Organizations don’t pick
371
00:20:29.960 –> 00:20:33.880
SharePoint for capability. They pick it for optics where maximizing investment,
372
00:20:34.000 –> 00:20:37.000
they say, ignoring that those savings vanish once the app grows.
373
00:20:37.559 –> 00:20:40.400
Data verse costs more. Yes, but you’re buying delegation, integrity,
374
00:20:40.400 –> 00:20:43.759
proper security, and ilam insurance that works when the fire starts.
375
00:20:44.240 –> 00:20:47.759
SharePoint tempts because it’s easy, quick set up, instant demo applause.
376
00:20:48.119 –> 00:20:51.279
Then resources crawls, screens freeze, and it gets blamed. The
377
00:20:51.319 –> 00:20:54.759
saving ends up spent on consultants rebuilding it in data verse.
378
00:20:55.440 –> 00:20:58.640
This pattern repeats constantly free tools lwed teams into expensive
379
00:20:58.680 –> 00:21:03.240
consequences at scale. That false economy burns more hours, wages,
380
00:21:03.279 –> 00:21:06.160
and patients than any data verse license ever. Would you
381
00:21:06.319 –> 00:21:09.519
saved twenty dollars per user? Excellent? That’ll cover a fraction
382
00:21:09.559 –> 00:21:12.680
of your next two hundred thousand dollars rebuilt. Microsoft didn’t
383
00:21:12.720 –> 00:21:15.160
hide the truth. They built data Verse for scale because
384
00:21:15.200 –> 00:21:20.319
SharePoint never was. Ignoring that boundary isn’t innovation, it’s negligence.
385
00:21:21.039 –> 00:21:23.960
File cabinets don’t run engines. Let’s end this with the
386
00:21:24.000 –> 00:21:28.440
matter for everyone remembers. SharePoint is a filing cabinet. Beautifully labeled,
387
00:21:28.599 –> 00:21:34.680
permission controlled, and spacious databases are engines, precisely tuned, pressure tested,
388
00:21:34.720 –> 00:21:38.240
and built for sustained power. One stores the other, computes,
389
00:21:38.319 –> 00:21:40.799
confuse the two, and your power up becomes a car
390
00:21:40.960 –> 00:21:44.680
powered by stationary. Every symptom you’ve met, slow galleries, broken
391
00:21:44.680 –> 00:21:48.160
look ups, failed migrations stems from that category era. SharePoint
392
00:21:48.200 –> 00:21:51.440
isn’t broken, your expectations are. It’s not that Microsoft misled you.
393
00:21:51.720 –> 00:21:54.440
It’s that you misapplied a product built for collaboration to
394
00:21:54.480 –> 00:21:57.960
a system demanding relational rigor. A filing cabinet can’t negotiate
395
00:21:57.960 –> 00:21:59.960
transactions anymore than a stapler can run an a lit
396
00:22:00.680 –> 00:22:03.839
And if you genuinely need scale, concurrency, security, and integrity,
397
00:22:04.039 –> 00:22:06.640
stop living on borrowed code. Move the data to data
398
00:22:06.720 –> 00:22:09.279
Verse or seql where it belongs. Yes, licenses cost money,
399
00:22:09.319 –> 00:22:11.759
so does electricity, gravity, and every other law of physics
400
00:22:11.839 –> 00:22:14.960
your business depends on. So here’s the blunt truth. Building
401
00:22:15.000 –> 00:22:17.359
an enterprise great power app on share Point is like
402
00:22:17.400 –> 00:22:20.480
balancing a skyscraper on Jello. It looks fine until someone moves.
403
00:22:20.839 –> 00:22:25.160
Then everything collapses slowly, expensively, and predictably. Don’t wait for
404
00:22:25.160 –> 00:22:28.720
your app to become a cautionary screenshot. Migrate now, budget properly,
405
00:22:28.759 –> 00:22:31.680
and treat architecture as non negotiable. If this explanation saved
406
00:22:31.720 –> 00:22:36.119
you a future rebuild, repay the favor, subscribe, tap follow,
407
00:22:36.480 –> 00:22:40.720
enable notifications, and get each new episode delivered like dependable patches,
408
00:22:40.960 –> 00:22:44.160
on time every time. Keep watching, keep optimizing, and stop
409
00:22:44.160 –> 00:22:45.839
mistaking filing cabinets for engines
