Power Apps priced storage like it was 2005
Microsoft sells a Power Apps Premium seat for $20 a user per month, paid yearly, and that seat comes with 250 megabytes of Dataverse database capacity. When you need more, the Dataverse Database Capacity add-on costs $40 per gigabyte per month. Supabase charges $0.125 per gigabyte on its Pro plan, past the 8 GB already included in the $25 subscription. Same gigabyte, same year, a 320x difference in what it costs to keep.
Where the bill actually comes from
Nobody signs up to Power Apps thinking about storage. You sign up because someone in operations needs an approvals app by Thursday and Microsoft will give you one, wired into the directory you already run, without a developer. That worked. The app shipped. Storage was a rounding error because the first year of data was a rounding error.
Year three is where the arithmetic turns. A modest line-of-business app with attachments, audit rows and a few years of history lands somewhere around 100 GB. Dataverse charges that as an add-on: 100 GB at $40 is $4,000 a month, on top of every seat you already pay for, and capacity packs pool at the tenant level so there is no per-app escape hatch. The same 100 GB of Postgres disk on Supabase Pro comes to $11.50 a month for the 92 GB past the included 8, plus the $25 plan. You are not paying for storage at that point. You are paying rent on the fact that the data lives somewhere you cannot reach.
The meter you did not know was running
Storage is the visible half. Microsoft also meters what Power Platform calls requests, and the definition is broad: every connector call, every Dataverse create, read, update or delete, every built-in Power Automate action down to initialising a variable. Failed actions count. Retries count. Pagination counts.
A paid Power Apps per user license gets 40,000 requests in a 24 hour window. A per app or pay as you go license gets 6,000. The part that catches teams is the tenant pool for non-licensed identities, the service accounts that run your nightly syncs and integrations: 25,000 requests per 24 hours for Power Apps, flat, with no accrual as you add seats. Hire twenty more people and your background jobs get exactly the same budget they had before. On Postgres a nightly sync is a query you profile and tune. Here it is a quota you cannot buy your way out of without changing license class.
What the other side looks like
We moved Stay World Class off Webflow and Xano onto Next.js, NestJS and Supabase. Lighthouse went from 55.91 to 91 out of 100 and LCP came down 77 percent. The migration ran as a four stage ETL that mapped every legacy ID to a PostgreSQL UUID, so nothing in the old system had to be renamed or abandoned on the way across.
The number that matters afterwards is not the performance score. It is that storage growth stopped being a pricing event. Adding a year of records changed a disk line by a few dollars instead of triggering a capacity conversation with a reseller. Requests stopped being a currency. Slow queries became something an engineer reads in a log and fixes, which is the ordinary condition of owning your own database and feels remarkable only after you have spent a few years not having it.
When staying is the right call
If your Power Apps footprint sits inside the 250 MB per seat entitlement and your flows stay well under 40,000 requests a day, the platform is doing exactly what you bought it for and the economics are fine. Nothing in the pricing page punishes a small app. Leave it alone.
The tighter case for staying is governance. If your apps live on Dataverse because it inherits Entra ID, conditional access and the compliance posture your auditors already signed off, rebuilding that on your own stack is real work you would be taking on deliberately, not a side effect of a migration. And if the team that maintains the app has no engineer on it, moving to Next.js and Postgres trades a bill you can forecast for a dependency you cannot staff. The moment to look hard at the numbers is when the storage add-on line starts rivalling the seat line, or when a background job starts failing at the same time every night. Until then the platform is holding up its end.
