Canvas apps vs model-driven apps

What it does

Two ways of building an app in Power Apps that share a platform and almost nothing else. A canvas app is screens and controls you place, wired together with Power Fx, over any data source with a connector. A model-driven app is composed from a Dataverse data model — tables, forms, views, charts, a site map — and the platform renders it.

Key facts

Model-driven apps run on Dataverse and only Dataverse. Without a data model in Dataverse you can't create one at all. Canvas apps reach Dataverse plus the whole connector catalogue.
Model-driven apps are responsive and accessible automatically. Canvas apps are responsive and accessible only if you designed them that way, which is a real line of effort in every estimate.
Microsoft's own comparison table rates migrating a model-driven app between environments as simple, and a canvas app as potentially complex because the data sources might need updating.
The Dataverse security model — table, row and column privileges, business units, teams, hierarchy — applies to a model-driven app with no work from you. A canvas app enforces whatever its data source enforces; screen-level logic in Power Fx is user experience, not security.
Building a canvas app doesn't need a licence. Building a model-driven app does. Running either can require premium depending on what it touches.
The two mix in two documented directions: a custom page brings a canvas-authored page into a model-driven app as a full page, dialog or pane; an embedded canvas app sits on a model-driven form and receives the record context.
Model-driven apps look and behave the same as each other. That consistency is the point — a user who has learned one has largely learned the next.

When to use / skip

The decision rule that actually holds up is data model gravity. If the requirement is relational — several tables, real relationships, users moving between related records, a process that spans them — the answer is model-driven, and it stays model-driven even when someone shows you a design mockup that model-driven can't produce exactly. If the requirement is a task performed at a specific moment by a specific role, on a device, in a shape the platform doesn't have — a field inspection, a stock count, a guided intake form — that's canvas.

"Canvas is pixel-perfect" is the reason people give and almost never the reason that matters. The two things that decide it in practice are the security requirement and the maintenance cost. Row and column-level security you'd get for free in model-driven becomes bespoke, testable, auditable work in canvas — and it's work that has to be redone every time the app changes. Maintenance runs the same way: a model-driven app absorbs a new column with a form change, and a canvas app absorbs it with a screen edit, a patch statement and a regression pass. Over three years that gap is bigger than the build cost either way.

Configuration decisions

Whether the data lives in Dataverse. Answer that first, because it settles most of the rest. If Dataverse is off the table for cost reasons, you've chosen canvas whether you meant to or not.
Whether the security requirement is expressible as Dataverse privileges, or is genuinely about what a user sees on a screen. The first is model-driven; the second is rarely as real as the client thinks.
If you go model-driven, where the canvas surface goes — a custom page, an embedded app on a form, or nowhere. Decide up front rather than bolting one on when a requirement gets awkward.
Who maintains it in two years, and whether that person reads Power Fx.
Whether users will meet several of these apps. Consistency is worth real money once there's more than one app in the estate.

Gotchas

A canvas app over Dataverse looks like it inherits Dataverse security, and it does — at the row level, through the connector. What it doesn't inherit is the form, view and command layer that made those privileges legible. People assume more transfers across than does.
Custom pages are canvas-shaped but not canvas apps. Behaviour, lifecycle and available functions differ, and a maker who knows canvas will trip over the differences.
Embedded canvas apps on a model-driven form carry their own performance cost and their own version. A form with three of them is a support case waiting to happen.
Teams that pick canvas for the visual design usually end up rebuilding navigation, search, filtering, sorting, accessibility and responsiveness that they'd have got for nothing. That work is invisible in the demo and very visible in the burn-down.
Dynamics 365 licences with limited Power Apps use rights only allow premium canvas apps to be played when embedded in a model-driven app as a custom page. Standalone play isn't included. That quietly forces the architecture on some accounts.

Consultant notes

Ask to see the entity-relationship diagram before you ask to see the wireframes. If there isn't one, that's the finding, and it usually points at model-driven.
Watch for the aesthetic argument standing in for a requirements argument. "It needs to look like our brand" is answerable in model-driven with theming and modern controls, and it's rarely worth a canvas rebuild.
Where the honest answer is both, say so early and design the seam. Model-driven for the record-keeping and process, canvas for the two or three moments that genuinely need a bespoke screen. That's a normal architecture, not a compromise.
Price the canvas option with the security and accessibility work included. Clients compare a full model-driven estimate against a canvas estimate that quietly omits half the delivery.

Worth revisiting whenever custom pages close another gap — the boundary has been moving towards model-driven for several waves