Fabric Apps, now in preview, gives you a database, an API, sign-in and hosting from one command. We spent time with it, and we are not yet sure who it is for.
What Fabric Apps is
Fabric Apps is a new item in Microsoft Fabric, currently in preview, for building custom web applications on your Fabric data. It is built on the Rayfin SDK. You describe your data model in TypeScript, deploy it with the Rayfin command line, and Fabric builds the pieces around it:
- A SQL database in Fabric, with its schema generated from your code
- A GraphQL API on top of it
- Sign-in through Microsoft Entra ID
- Hosting for your front end, plus file storage
It all runs on your Fabric capacity, so everything the app does draws on the capacity you already pay for. Fabric Apps is separate from org apps, which are another preview feature, so check which one a colleague means before you compare notes.
What it does well
Getting a working app in front of people is quick. The database, API, authentication and hosting arrive together, and connectors give typed access to the things you already have in Fabric: lakehouses, warehouses, SQL databases and semantic models. Microsoft also documents building an app with an AI coding agent such as GitHub Copilot or Claude Code.
Where we are not sure
We spent time building an app with it, and three questions kept coming up.
Who is it for?
It is not a tool for beginners. The back end is TypeScript, you work from a command line, and running it locally needs a local stack that uses Docker. We built ours in VS Code with an AI coding agent, and it felt like any other development project.
We already build apps that combine dashboards with data entry, as in our Client: us case study. So for an engineer who is comfortable with all of that, the question is why not build a web app directly, with an agent, and host it where you choose. Fabric Apps saves some plumbing, but plumbing is the part a coding agent is now good at.
What does it cost?
Every part of an app draws on your Fabric capacity: the database, the GraphQL API (billed at 10 capacity units per hour of request processing time), user data functions and storage. At the time of writing, Microsoft's pricing page lists the meters but gives no dollar prices, no worked example, and no statement on how the database is billed when the app is idle.
We were surprised by how much capacity our app consumed. On an F8 capacity, a very basic prototype app showed interactive workloads of 20 to 30 per cent. We do not have detailed usage statistics, so treat that as one data point rather than a benchmark.
Compare that with how we host our own apps: a small Azure App Service plan, tier B1, with one core, 1.75 GB of memory and 10 GB of storage. It easily handles a front end and a back end together, and on Linux it costs about £10 a month. The plan also sits outside your analytics capacity, so the cost is fixed and visible before anyone uses it.
To be fair to Fabric, the SQL database in Fabric is a reasonable place to keep data, and we see no problem with using it. We did not use it in our own app because the app already reads several databases that sit in an elastic pool. The difficulty is that its cost is unclear.
Do we want a database for every app?
Each app gets its own managed database. Microsoft's FAQ says you cannot point an app at an existing database with a predefined schema, and the schema can only be changed through code, not in the portal. Connectors reach your lakehouses, warehouses and semantic models, but the app's own data lives in its own database.
Encourage people to build this way and you can end up with 50 or 100 small databases, each doing one job, each needing an owner and a security review. Compare that with bringing data together in fewer, shared places. We could not find anyone else raising this yet, so treat it as our observation rather than an established problem.
Limits to know about
From Microsoft's own FAQ:
- No custom SQL or stored procedures, so complex multi-step transactions may not suit
- No many-to-many relationships, and every table needs a single UUID key
- Sign-in is Microsoft Entra ID only, so it suits internal tools, not a customer portal
- No multiple environments or application lifecycle management out of the box
- Not available in all regions yet
Where it could make sense
Small internal tools used by people who already work in Fabric, with write-back to a database that sits next to a semantic model, where you have capacity to spare and want everything in one governed place. It is also a quick way to put a working prototype in front of users.
Our verdict: watch it
We would not build client work on it yet, and we would not rule it out. Four things would change our mind:
- Published prices and a worked cost example
- A way to share a database between apps, or to use an existing one
- Environments and lifecycle management
- General availability
What others are saying
Independent commentary so far is cautious. Writers describe it as a preview to evaluate before production, note that sign-in is limited to Entra ID users, and stress planning cost against capacity. Some raise vendor lock-in and the limits of a Fabric-managed database for live operational work. We have not yet seen anyone weigh the capacity cost or the number of databases the way we have above.
Sources
- What is Fabric Apps (preview)?, Microsoft Learn
- Fabric Apps pricing and billing, Microsoft Learn
- Fabric Apps FAQ, Microsoft Learn
