Dataverse vs SharePoint vs Azure SQL

What it does

Three places a Power Platform app can keep its data, chosen for entirely different reasons. Dataverse is a relational platform with a security model, business logic and ALM built in. SharePoint lists are a document platform being used as a database. Azure SQL is a database with none of the platform on top and all of the control underneath.

Key facts

Dataverse gives you row-level and column-level security, business units and teams, server-side business logic, auditing, change tracking, solutions and ALM. Nothing on that list exists in SharePoint lists, and all of it is your problem to build on SQL.
SharePoint list view thresholds and delegation limits are the practical ceiling. Power Apps delegation against SharePoint is partial, so filters that look fine on 200 rows quietly stop being correct at 20,000.
SharePoint has no referential integrity, no cascade behaviour, no transactions and no server-side validation. A lookup column is a pointer with nothing enforcing it.
Azure SQL through the connector supports delegation well and handles volume and complex queries better than either alternative, but every app touching it needs connection management, and security is whatever you implement in the database.
Dataverse capacity is licensed and metered by database, file and log storage. SharePoint storage comes with Microsoft 365. Azure SQL is billed as an Azure resource. Three completely different cost shapes — check the Power Platform licensing guide rather than assuming.
Premium licensing: Dataverse-backed apps need a Power Apps premium licence. So does the Azure SQL connector. SharePoint is a standard connector. That's usually the actual driver of the argument.
Only Dataverse participates in solutions. SharePoint list schema and SQL schema have to be deployed by some other mechanism you own.

When to use / skip

The honest rule: if the data has a security requirement, a relationship, or a lifecycle, use Dataverse. If it's a list of things one team maintains and nobody outside that team cares about, SharePoint is fine and you should stop over-engineering it. If it's high volume, already exists in a database, or a platform team already runs SQL for you, use Azure SQL and put a Power App on top.

Where people go wrong is treating this as a cost decision. It isn't. SharePoint looks free because the licence is already bought, and the bill arrives eighteen months later as a rebuild — when the list hits the view threshold, when someone asks for record-level security, when the compliance team asks who changed a value and there's no audit. If any of those three requirements exist at design time, SharePoint is already the wrong answer and the licence saving is a loan, not a discount.

The genuinely hard case is the middle one: a departmental app with 30,000 rows, no security requirement and a tight budget. That's the only place I'd argue seriously for SharePoint, and I'd still write down what would force a move.

Configuration decisions

Does any requirement mention who can see which rows? That single question settles it for Dataverse more often than anything else.
What's the realistic five-year row count, and does it clear delegation limits on the platform you're choosing?
Who owns the schema deployment path — solutions, or something you're going to have to build?
Is there already an Azure landing zone and a team who run databases? If yes, SQL is a much easier operational sell than Power Platform people expect.
Is the premium licence already in the estate? If the client has Dynamics 365 or Power Apps premium, the main argument for SharePoint has already evaporated.

Gotchas

SharePoint delegation warnings in the Power Apps studio are advisory and easy to dismiss. The app doesn't break; it silently returns wrong results once the data grows past the delegation ceiling.
Migrating SharePoint to Dataverse is not an import. Lookups, attachments, versioning, item-level permissions and any flow referencing list item IDs all need rework. Budget it as a rebuild with a head start.
Azure SQL through the connector still needs a gateway if the database isn't reachable from the cloud, and the gateway becomes a piece of production infrastructure with an owner and a patch cycle.
"We'll just use SharePoint for now" is the most expensive sentence in Power Platform delivery. It never gets revisited until it fails.
Dataverse storage is the cost people forget. Audit logs, file columns and plug-in trace logs consume capacity buckets clients aren't watching until the notification email arrives.

Consultant notes

Make the client articulate their security requirement before you discuss platforms. Nine times in ten it decides the answer and saves a week of comparison workshops.
Write down the trigger conditions that would force a migration off SharePoint, and put them in the design document. It converts a shortcut into a managed decision.
If the estate already has Dynamics 365, the licensing argument is over. Say so early rather than letting someone re-litigate it every sprint.
Mixed estates are normal and fine. Dataverse for the core entities, SharePoint for documents, SQL for the analytical or high-volume side. What matters is a written rule for which side of the line new work falls on.

Revisit whenever the Power Apps licensing shape changes — the SharePoint argument is almost always really a licensing argument