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 Is
Let’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 Myth
Microsoft 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 layering patchwork fixes: smaller galleries, manual caching, “collection” tricks to load subsets of data. It looks like progress but only delays the inevitable. It’s like rearranging deck chairs on a server farm that’s on fire.
People mistake reliability for survival time. “It’s worked for months,” they say, proudly ignoring the trend line. A proper database scales predictably: more data means slightly more storage, not exponentially slower queries. SharePoint scales emotionally—it starts healthy, then suddenly collapses like it just remembered it’s a web service from 2003.
And yet, the illusion persists because Microsoft includes SharePoint in the license. The tool is approachable, the setup effortless, and the first prototype thrillingly quick. But free convenience hides catastrophic economics. Each delay compounds across users, departments, and workflows until productivity losses dwarf any licensing savings. The irony? The organization eventually pays far more for an “included” feature than it would have for Dataverse’s so‑called premium price.
You wanted relational joins across lists? Fascinating. Do you also expect teleportation? Because that’s about as plausible inside SharePoint’s architecture. The list interface wasn’t built for transactional queries or complex aggregation. It’s a collaborative document store that’s being forced—daily—to impersonate a relational database. No wonder it looks tired.
So, the next time someone quotes that thirty‑million‑item limit, pause. Ask them how many they’ve actually queried successfully in Power Apps without freezing the app. The number will be much smaller, somewhere between “few thousand” and “please don’t ask.” That’s not scale; that’s tolerance. And tolerance runs out. What follows it is the crash every Power App team eventually experiences—the day their “free database” becomes a very expensive bottleneck.
The visible slowdown is just the start. What comes next is subtler—the kind of corruption hidden behind seemingly normal forms and lookups. Because while performance pain screams, integrity failure whispers. And in the next section, those whispers turn into full‑blown data chaos.
Section 3: Relationships, Lookups, and Other Dangerous Illusions
Now we reach the part where SharePoint proudly pretends to be relational. It waves its little lookup column and declares, “See? I can do relationships too.” No, you can’t. Not the kind that matter. Not the kind with referential integrity, cascading updates, and proper foreign keys. What SharePoint offers is a child’s drawing of a database scribbled in crayon—cute from afar, horrifying up close.
In a real database, relationships are contracts. Table A promises to link only to valid records in Table B. If you delete something in B, the database enforces what happens next: either block it, cascade it, or update accordingly. Integrity is law. SharePoint, by contrast, treats relationships as gossip—“I heard record X might know record Y, but who can say, really?” Delete the parent list item and the child keeps an orphaned reference, quietly rotting until a user clicks it and gets an error that looks like a riddle.
Developers cling to lookup columns thinking they’re safe. They’re not relationships. They’re lightweight pointers that store the ID and a bit of display text, nothing more. They don’t validate consistency. They don’t prevent duplicates. They simply assume nothing will go wrong, which is adorable. And when Power Apps uses those lookups, it has to perform multiple calls: one to retrieve the main list, another to resolve each lookup. That’s dozens of round trips just to reconstruct what SQL would fetch in one JOIN. Every lookup adds lag, every nested gallery doubles it.
Choice columns are equally misleading. They look like constraint enforcement—preset options, clean UI—but under the hood they’re glorified text fields decorated with dropdowns. Each choice is stored as plain text or sometimes JSON‑flavored markup depending on column settings. Good luck filtering efficiently. Dataverse translates options into integer‑mapped sets for quick comparison. SharePoint just sifts through strings the way a librarian searches a card catalog in the dark.
Then we have the illusion of normalization. In legitimate database design, normalization prevents redundancy; each entity lives exactly once, saving space and ensuring consistency. SharePoint nods politely and does the opposite. Lists operate in parallel universes. You can normalize manually—split your data into multiple lists and reference them—but every lookup slows performance. Normalize too much and your Power App spends its life resolving relationships instead of serving users. Denormalize to simplify performance and you sacrifice integrity, turning your lists into mutant hybrids full of duplicated values. It’s a lose‑lose game designed by someone who mistook sheet music for a soundtrack.
The practical outcome? Most Power Apps running on SharePoint settle into lazy denormalization. Each list becomes a wide table stuffed with repeating data just to avoid fetching lookups. It feels efficient until the data starts drifting—department names misspelled, users duplicated, references out of sync. By month three, your “database” agrees with itself about as much as conspiracy theorists at a flat‑earth convention.
Power Apps compounds this with its handling of data calls. Each “related” record shown in a form is fetched via a separate query. Occasionally, caching masks the inefficiency, but open a deep form with multiple lookups—Client, Product, Manager, Status—and behind the scenes SharePoint is juggling a small crowd of network requests. Any latency along the way multiplies. The result is that users open a record, wait a few seconds, then start clicking out of frustration—triggering another round of premature network chaos.
Developers respond with clever but ruinous workarounds. Collections, local caches, manual JSON parsing—all in the name of pretending relationships behave like SQL joins. It works briefly, until update conflicts appear. Someone edits from a mobile version while another user edits the same record in the browser. SharePoint doesn’t negotiate; it simply overwrites. One person wins, the other loses silently. The system smiles and tells you everything saved correctly. It didn’t.
Imagine running a bank ledger on post‑it notes. Each lookup column is another sticky label you might misplace. At small scale, you can keep track. Once the wind picks up—say, concurrent users, bulk updates, or automated flows—the notes scatter. That’s SharePoint relationships. Held together by duct tape and hope, forever one sneeze away from chaos.
Even more deceptive is how friendly it feels at first. The interface offers “easy linking” between lists. You click a dropdown, pick “Lookup from another list,” and instantly it seems powerful. But underneath, no relational metadata exists—just stored text with a fragile correlation ID. Delete or rename the target column and you’ve broken the map. Power Apps tries to follow the trail and falls through a logic hole. Debugging that is like tracing spaghetti in a fog.
Normalization evangelists eventually face an existential crisis. They design beautifully structured SharePoint lists: Employees, Departments, Projects, each with crisp lookups. Then they publish the app, and users complain it’s unbearably slow. The architects capitulate, merge lists, denormalize data, and accept the compromise. SharePoint rewards disorder, punishing proper design. It’s the academic equivalent of a teacher docking points for turning in grammar that’s too correct.
By now you should see the broader point: SharePoint doesn’t understand relational theory because it was never meant to. It’s built for storing documents, comments, and metadata about those documents—not executing complex relational logic. The moment you rely on it to maintain relationships, you’re forcing a librarian to perform as a database administrator. It smiles, pretends to help, then misfiles half your records behind the photocopier.
And yet, people remain hopeful. “Maybe security makes up for it,” they say, as though item‑level permissions could save structural design. Spoiler: they can’t. Security may look like order, but when applied at SharePoint’s microscopic scale, it becomes another performance trap. So before you declare victory because “our lists have lookups,” pause and check the integrity. If the links break and nobody notices until the quarterly report, you’ve built a time bomb—quiet, polite, and waiting.
Next, let’s test whether security really redeems any of this architectural chaos—or if, like the rest, it’s merely another illusion wrapped in a SharePoint smile.
Section 4: Security, Lifecycle, and Tech Debt
Ah yes, the comfort blanket of every SharePoint apologist—security. “But it has amazing permissions,” they say. Technically true. Functionally disastrous. SharePoint does, in fact, let you assign security at almost any level imaginable—site, library, list, item. You can lock down a single row so tightly that even its creator can’t find it again. It’s a marvel of granularity. It’s also a nightmare of maintainability.
In a real database like SQL or Dataverse, security operates predictably. You define roles—reader, contributor, admin. Those roles apply at the table, row, or even column level depending on the engine. There’s structure. There’s logic. The boundaries are enforced systematically, not emotionally. SharePoint, however, applies security like confetti at a wedding: it’s everywhere and no one remembers who threw it.
Each time you break inheritance on a list item, SharePoint creates an independent access control list entry. Sounds fine until you have hundreds, then thousands, each demanding separate evaluation by the permission engine. That’s when queries slow down—not because your data’s complex, but because SharePoint is busy recalculating who’s allowed to see which row. You wanted granular security; you got molasses.
Picture a librarian checking ID before handing out every individual page of a book. It’s technically secure, yes, but you’ll die of boredom before finishing chapter one. SharePoint does exactly that across your list views. The result? Performance collapses proportionally to how “secure” you tried to make it. True database platforms handle this with row-filtered views and role-based access at query time—one efficient rule set applied dynamically. SharePoint brute-forces it at load time. Genius, in a sort of medieval way.
Now add Power Apps to that equation. Every time the app opens a gallery, it authenticates through your context, fires off list queries, and evaluates those permissions one item at a time. Users think their device is slow; in reality, it’s SharePoint playing bureaucrat, stamping each record “approved for viewing” before rendering the screen. Multiply that across hundreds of users, and the infrastructure wheezes like a fax machine in 2024.
This is where most teams start introducing “shortcuts” to save themselves. They duplicate data into unsecured lists for convenience’s sake, or create automation that copies “safe” subsets nightly. Congratulations—you’ve just built shadow databases without integrity constraints. Security becomes a patchwork of wishful thinking. And with no centralized schema or role-based system, auditing who can see what turns into an archaeological dig through broken inheritance chains.
But security’s only the first layer of dysfunction. Let’s talk lifecycle management—the grown-up part of any software system. In proper database environments, you migrate through environments effortlessly: Development → Test → Production. Dataverse packages tables neatly inside Power Platform Solutions. SQL exports its schema in a single script. SharePoint? It stares blankly, mutters something about “list templates,” and leaves you to figure out the rest.
Moving a SharePoint data model between environments is like cloning Frankenstein: theoretically possible, practically horrifying. Columns lose types. Choice values mutate. Lookup IDs regenerate like chaotic DNA. Automated provisioning scripts attempt to recreate lists by name, only to discover that SharePoint’s internal identifiers don’t align across sites. The resulting environment might look similar on the surface, but underneath it’s a totally different creature, stitched together with mismatched limbs and fragile wiring.
Then you hit the “content migration” phase, where developers try to copy test data to production. SharePoint doesn’t have true export-import parity; instead, you rely on JSON templates, PowerShell scripts, or third-party tools that charge per gigabyte of despair. Migrate a thousand items, lose twenty lookups, and watch your Power App crash because half its relationships now point to nonexistent records. That’s not a migration—it’s a funeral.
Even versioning, one of SharePoint’s banner features, becomes treacherous. The platform dutifully keeps historical copies of items, but Power Apps doesn’t integrate meaningfully with that version history. When something breaks, you can technically roll back, but you’ll lose relational context in the process. Dataverse tracks changes transactionally; you can restore state coherently. SharePoint just hands you a random past snapshot and says, “Good luck reconciling this mess.”
The tragedy here is cumulative. Each fragile list, each manual security rule, each hand-crafted migration adds invisible weight. That’s technical debt—the system equivalent of cholesterol. It clogs everything. Time that should go into improving your app instead goes into maintaining permission hierarchies and rebuilding lists that fail silently.
And the kicker? Most of that debt accrues because of a single flawed assumption: that SharePoint was “free,” so cutting corners was justified. The next section rips the bandage off that illusion. Spoiler alert—the free option always charges interest later.
Section 5: The Licensing Trap and the “Free” Fallacy
Here’s the root of this chaos: accountants love “free.” The Power Platform license includes SharePoint, so using it feels thrifty. No approvals, no budget fights—until later, when the hidden technical debt arrives disguised as maintenance, frustration, and rebuild costs.
Organizations don’t pick SharePoint for capability; they pick it for optics. “We’re maximizing investment,” they say, ignoring that those “savings” vanish once the app grows. Dataverse costs more, yes, but you’re buying delegation, integrity, proper security, and ALM—insurance that works when the fire starts.
SharePoint tempts because it’s easy: quick setup, instant demo, applause. Then resources crawl, screens freeze, and IT gets blamed. The “saving” ends up spent on consultants rebuilding it in Dataverse.
This pattern repeats constantly. Free tools lure teams into expensive consequences. At scale, that false economy burns more hours, wages, and patience than any Dataverse license ever would.
You “saved” twenty dollars per user? Excellent. That’ll cover a fraction of your next two‑hundred‑thousand‑dollar rebuild. Microsoft didn’t hide the truth—they built Dataverse for scale because SharePoint never was. Ignoring that boundary isn’t innovation; it’s negligence.
Conclusion: File Cabinets Don’t Run Engines
Let’s end this with the metaphor everyone remembers. SharePoint is a filing cabinet—beautifully labeled, permission‑controlled, and spacious. Databases are engines—precisely tuned, pressure‑tested, and built for sustained power. One stores; the other computes. Confuse the two, and your Power App becomes a car powered by stationery.
Every symptom you’ve met—slow galleries, broken lookups, failed migrations—stems from that category error. SharePoint isn’t broken; your expectations are. It’s not that Microsoft misled you; it’s that you misapplied a product built for collaboration to a system demanding relational rigor. A filing cabinet can’t negotiate transactions any more than a stapler can run analytics.
If you genuinely need scale, concurrency, security, and integrity, stop living on borrowed code. Move the data to Dataverse or SQL where it belongs. Yes, licenses cost money. So does electricity, gravity, and every other law of physics your business depends on.
So here’s the blunt truth: building an enterprise‑grade Power App on SharePoint is like balancing a skyscraper on Jell‑O. It looks fine until someone moves. Then everything collapses—slowly, expensively, and predictably.
Don’t wait for your app to become a cautionary screenshot. Migrate now, budget properly, and treat architecture as non‑negotiable.
If this explanation saved you a future rebuild, repay the favor: subscribe. Tap “Follow,” enable notifications, and get each new episode delivered like dependable patches—on time, every time. Keep watching, keep optimizing, and stop mistaking filing cabinets for engines.
