Choosing Between SharePoint, Dataverse and SQL for Power Apps
Choose storage from required behaviour, security and ownership, not familiarity alone.
The least useful question in Power Apps architecture is, “How many rows can SharePoint handle?” It invites a feature-limit comparison when the real decision is about behaviour, ownership and consequence.
SharePoint, Dataverse and SQL can all store rows. That is about where the similarity ends.
Start with the shape of the work
SharePoint is a collaboration platform. Lists are a natural fit when people already work around sites, documents and Microsoft 365 permissions, and the data model remains modest. A team register, lightweight approval tracker or document-centred process may be entirely appropriate. SharePoint becomes uncomfortable when the application needs a rich relational model, transactional updates or security rules that users can no longer understand from the site.
Dataverse is an application data platform. Relationships, choices, auditing, business units, security roles, solution packaging and Power Platform integration are native concepts. It is usually the strongest default for a material Power Platform product whose lifecycle lives in the platform. The licence cost is visible, which makes it easy to criticise; the engineering and operational cost avoided by using native behaviour is less visible.
SQL is a database service. It fits when the organisation already owns a relational data product, needs complex queries or transactions, or expects several applications outside Power Platform to share the same service. SQL provides capability, not an operating model. Somebody still needs to own schema changes, APIs or direct access, identity, availability, backups and performance.
Compare behaviours, not product names
I would make the decision against a concrete set of questions:
| Question | Why it changes the choice |
|---|---|
| Does the data have real relationships and integrity rules? | Recreating relational behaviour in formulas or flows creates fragile application logic |
| Are multi-record changes required to succeed together? | Transaction boundaries matter more than raw row capacity |
| Is access determined by record, role, team or hierarchy? | Complex authorisation built from SharePoint item permissions becomes opaque quickly |
| Will several applications or platforms own the data? | Shared data needs a deliberate service and contract |
| How will queries delegate at realistic scale? | A connector returning data is not proof that the required query executes safely server-side |
| How will schema and configuration move between environments? | Production change must be reproducible, reviewable and recoverable |
| Who supports the service at 10:00 on a Tuesday? | A technically capable store without an owner is a future incident |
Volume belongs in the discussion, but it is rarely decisive by itself. A small dataset with complicated permissions and financial consequences may demand more architecture than a large read-only reference list.
Beware the cheap workaround
Teams often choose SharePoint to avoid premium licensing, then reproduce missing platform behaviour through flows, hidden columns, item-level permissions and collections loaded into the client. The licence line becomes cheaper while delivery, testing and support become more expensive.
The opposite mistake also happens. Dataverse is selected because the application is built in Power Apps even though the organisation already has an authoritative SQL-backed service. Copying that data creates synchronisation, identity and ownership problems. Platform alignment is not a reason to invent a second system of record.
Hybrid is an architecture, not a compromise word
A Power App can use SharePoint for documents, Dataverse for application state and an API backed by SQL for an existing enterprise capability. That can be the correct design. Each boundary must have an explicit purpose, identity model, failure behaviour and owner.
Avoid distributing data simply to escape one limitation or licence. Every copy creates questions about freshness, deletion, permissions and authority. If nobody can say which store wins when values disagree, the design is unfinished.
Choose the platform whose native behaviour matches the requirements that are hardest to compromise, and whose ownership matches the team that will operate it. Workarounds are architectural costs even when procurement does not put them on the first invoice.