SharePoint vs Dataverse is a business-data and governance decision, not simply a storage comparison. SharePoint Lists can fit relatively simple Microsoft 365 workflows. Dataverse suits Power Platform-native applications with richer relationships, security and lifecycle needs. Azure SQL fits controlled relational workloads and existing SQL estates. Query delegation, backend authorization, actual user entitlements and long-term support determine whether each option is defensible.

Quick decision: which backend should you choose?

Begin with the users and transactions rather than an arbitrary row threshold. Specify who can see or change which record, what relationships must remain valid, which queries must be complete, and how updates are deployed. A low subscription increment can be outweighed by custom security, synchronization or recurring operational work. Test the most difficult query and permission boundary before committing.

What is different about these data platforms?

SharePoint Lists organize typed columns, views and list-oriented workflows. Lookup columns can connect related information but should not be treated as a general substitute for a deliberate relational model. SharePoint permissions and document collaboration can fit simple departmental applications; excessive item-level exceptions can create administration that a small pilot never reveals.

Dataverse provides business tables, relationships, roles and platform capabilities used by canvas and model-driven applications. It adds application and governance abstractions beyond storing rows. Solutions and environment strategy support managed delivery. See Why choose Dataverse. Do not assume all features or capacities are included in every entitlement.

Azure SQL is a relational database platform with tables, indexes, queries, views and stored procedures. The database team owns schema, query performance and database authorization, while the app team owns supported connector usage and app behavior. An API-mediated design can be useful when business operations need a controlled contract rather than exposing broad table access directly.

SharePoint vs Dataverse vs Azure SQL: detailed comparison

Architecture: how Power Apps reaches each backend

Draw the identity boundary, not just the arrows. Determine whether the backend sees the individual user or a configured shared connection, and what that identity can do outside the intended screen. Review SQL security with Power Apps before sharing an app. Secure implicit connection features and database permissions require configuration; UI obscurity is not protection.

Performance, scalability and Power Apps delegation

A delegable Power Fx expression can be translated into a server-side query. A nondelegable expression can operate over a limited local subset and return an incomplete answer without the user understanding why. The current delegation documentation must be checked for the selected connection, column type and complete formula. Do not publish a universal 2,000-record platform maximum.

The SharePoint 5,000-item list-view threshold is distinct from Power Apps query limits and from how much data a list can store. Index relevant columns and design selective views/queries. Increasing a client-side row setting does not repair an inherently incomplete filter. For SQL, investigate query plans, indexes and returned columns; for Dataverse, review relationship/query shape, security filtering and platform request behavior. See SharePoint connection guidance.

// Illustrative Power Fx; validate delegation for actual connector/column types.
Filter(Orders, StatusText = "Open")
// Review warnings and support rather than assuming a transformed-column expression delegates:
Filter(Orders, Lower(CustomerName) = Lower(SearchBox.Text))

Build a test dataset containing known matching records deliberately beyond the configured nondelegation limit. Compare the app’s result with an authoritative backend query, including sort order and boundary values. Repeat under a normal user’s permissions. Test connector throttling and concurrent writes, not only a gallery populated from a tiny developer dataset. Record the exact formula and schema with the evidence so a later field-type change cannot silently invalidate it.

Licensing and a transparent 36-month TCO

SharePoint’s availability within an eligible Microsoft 365 scenario does not establish rights for every app or connector. Dataverse and SQL paths require their applicable Power Apps entitlements; database/capacity, integration and operating costs remain separate. Consult Power Apps licensing FAQ and the current agreement. Review any announced February 2027 enforcement changes against current official notices before procurement; this draft does not assume unverified future terms.

Use TCO36 = licenses + database/capacity + implementation + integration + security/governance + maintenance + support. Record region, currency, price date, term, capacity and excluded costs. No vendor prices are supplied here. Allocate shared platform costs once, count migration and recovery work, and compare plausible growth scenarios. A cheap first screen can become expensive if data ownership and permissions must be rebuilt later.

Security, compliance and governance

Classify data and test row/column access in the backend. SharePoint membership, Dataverse roles/business units and SQL principals implement different security models; they are not synonyms. Choose connection identity deliberately, apply least privilege, review audit scope and retention, and document who can export or integrate the data. A business rule or hidden control is not a replacement for backend authorization.

Separate environments and version app/configuration changes. Dataverse solutions can help with platform ALM, while list schemas and SQL database changes need their own governed deployment process. Define restore tests, capacity alerts and flow ownership. See Power Platform ALM basics. A cloud service or premium license does not by itself establish regulatory compliance.

Six hypothetical enterprise use cases

Choose SharePoint when the list model and Microsoft 365 operating model remain sufficient. Choose Dataverse when platform-native relationships, security and lifecycle earn their cost. Choose SQL when existing data architecture and controlled relational operations dominate. Dataset size alone does not make this decision: a small dataset with complex authorization can be harder than a large, well-indexed reference list.

Can the three platforms be used together?

Yes, when each owns a distinct responsibility: for example, SharePoint holds documents, Dataverse manages a case, and SQL remains the source of an operational master record. Define which fields are authoritative, permitted latency and the recovery contract. Avoid bidirectional updates without conflict rules. A successful connector call does not prove the business records are reconciled.

SharePoint-to-Dataverse migration roadmap

1. Inventory lists, columns, lookups, attachments, flows, users and downstream dependencies.
2. Define record ownership, business rules and target authorization before mapping fields.
3. Design target tables/relationships and validate licenses and capacity.
4. Clean duplicates, map identities, and migrate a representative slice including attachments and edge cases.
5. Rebuild affected formulas, connector references and flows; do not copy permissions blindly.
6. Reconcile counts and business totals; test complete queries and denied access under normal roles.
7. Rehearse cutover, freeze/redirect writes as required and retain a recoverable source snapshot.
8. Monitor synchronization, exceptions, capacity and user acceptance before decommissioning.

Rollback must account for writes made after cutover. A restored app version cannot reverse newly entered data or changed authorization. Decide whether recovery means reversing traffic, replaying a delta or restoring data, and test that route. Keep the source authoritative until the agreed acceptance checks pass; avoid two uncontrolled writers during migration.

Decision matrix, common mistakes and production readiness

• Do not confuse a list-view threshold with storage capacity.
• Do not ignore delegation warnings or hide them with a larger client limit.
• Do not treat all relational backends as identical Power Platform services.
• Do not omit Dataverse entitlements or SQL connector licensing.
• Do not trust client filters for security.
• Do not accumulate uncontrolled lookup and permission exceptions.
• Do not deploy an app without schema, flow and identity change management.
• Do not compare platform fees while excluding recovery and operational support.

Production acceptance requires representative query/load tests, correct user entitlements, denied-access evidence, monitored connectors, a restore rehearsal and a named support owner. Store the architecture decision and its assumptions with the app. Revisit it when a new department, sensitive field or synchronization requirement changes the risk—not only when a record count crosses a convenient number.

Frequently asked questions

Technical references

• Why choose Dataverse
• SQL security with Power Apps
• delegation documentation
• SharePoint connection guidance
• Power Apps licensing FAQ
• Power Platform ALM basics

Technical source review: 1 November 2026. Illustrative architectures, assumptions and examples are not client implementations or measured production results. Deployment-specific verification is required.