SharePoint Is NOT a Database: The Power Apps Lie

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