Co-authored by

Can You Build an Application on Microsoft Fabric?

Quick answer: Yes. Fabric Apps, in public preview since Microsoft Build 2026 and still preview in October 2026, hosts a custom-coded web frontend with Entra sign-in and a managed SQL database behind a GraphQL API. Whether it can host your application depends entirely on what that application does when nobody has it open.

Most coverage of Fabric Apps since Build answers a question nobody building software actually asks: what is it? The question that decides a budget is narrower. You have an application — or a proposal to build one — and someone in the room says the analytics platform can host it now. How much of it, exactly?

This post answers that component by component, against Microsoft's own documentation as of 21 July 2026, re-checked and corrected on 29 July 2026 against apps we have since deployed, and updated on 18 October 2026 for the changes Microsoft announced at FabCon Europe 2026. It is deliberately not a rerun of our breakdown of the four Fabric app capabilities, which separates the Fabric Apps item type from translytical task flows, Power Apps on OneLake, and the Extensibility Toolkit. Read that one if you're still working out which "Fabric app" people mean. This one assumes you know, and asks whether it can carry your build.

It also assumes the build is warranted. If that part is still open, when to use Power BI vs a custom application settles it first — half of what teams scope as an application turns out to be a report.

Fabric Apps Services: Database, Auth, and Hosting

Quick answer: Three core managed services: static frontend hosting, Microsoft Entra SSO, and a Fabric SQL database exposed over GraphQL, deployed through an open-source TypeScript SDK called Rayfin. FabCon Europe 2026 added connectors, server-side functions and a secret store in preview.

Microsoft describes a deployed Fabric App as a set of child services:

Three endpoints are exposed on the app's backend URL: /api/graphql for data, plus /auth and /storage. App-owned data runs through the generated GraphQL API.

The table has no GraphQL row. The API is a path on the backend endpoint, generated from your data model rather than provisioned alongside it.

FabCon Europe 2026 added services around that table, all in preview: data connectors, PostgreSQL support, server-side functions, secret storage, application storage and built-in metrics, per Microsoft's what's new page. Connectors reach a lakehouse SQL endpoint (read only), a warehouse or SQL database in Fabric (read and write), or a semantic model (executeQuery). The FAQ still names only SQL Server as a database.

The SDK is real and open source. Rayfin uses a decorator-driven TypeScript model (@entity(), @uuid(), @text(), @role()) to generate the database schema, the GraphQL layer, and a typed RayfinClient from one definition. It ships as npm packages (@microsoft/rayfin-cli, @microsoft/rayfin-core, @microsoft/rayfin-client), and the source is public at github.com/microsoft/rayfin. Microsoft's troubleshooting page still links a microsoft/project-rayfin repository that returns a 404.

Fabric Apps Templates: SQL Database vs Semantic Model

The service table doesn't tell you that there are two templates, and they are different data architectures rather than variations on a theme.

That write column is the one to sit with. A semantic model is a read surface, so an override, an approval or a mapping correction has to land somewhere else. Before FabCon Europe 2026 a dataapp build had nowhere to put it. Now a warehouse or SQL database connector supports create, update and delete, so one app can read the model and write to a Fabric table. Decide that write target before you start, not after the first user asks for an override.

For a BI estate this is the more interesting template, and it's the one most coverage skips entirely. Microsoft's own page for it is worth reading before you choose.

This is not a low-code tool. The FAQ says it "works with any frontend framework that can make HTTP requests: React, Vue, Angular, Svelte, Vanilla JavaScript/TypeScript." React with Vite is the default scaffold, not a requirement.

What Fabric Apps Can and Can't Host

Quick answer: The frontend and its CRUD layer fit cleanly. Server-side functions added at FabCon run on request, for up to 240 seconds. Anything that must keep running while no user has the app open has no documented path in Fabric Apps.

Take a working application apart and check each piece against what Microsoft documents:

The wording in that table matters, and it is more careful than most commentary on this topic. I checked, and on 18 October 2026 re-checked, the Fabric Apps overview and FAQ for ten terms: WebSocket, SSE, Server-Sent, real-time, background, worker, long-running, cron, scheduled job, and always-on. None of them appear on either page. Not as supported features, and not as stated limitations.

So the honest claim is not "Fabric Apps cannot do these things." It is that Microsoft documents hosting, auth, data, connectors and request-driven functions, and nothing that runs on its own. Fabric has a separate preview for scheduled User Data Functions, but Microsoft does not document it for Fabric Apps. A platform that never mentions background execution is not one to bet an always-on requirement on without a written answer from Microsoft.

What Microsoft does commit to is the shape of the thing:

"A Fabric app runs as a managed service in Fabric with a suite of services that define the backend such as app hosting, database, GraphQL APIs, and authentication. Fabric manages the hosting, networking, and scaling."

And a short list of what it isn't for, including "applications requiring complex multi-step transactions or stored procedures."

The practical read: if your application is a user interface over data that lives in Fabric, this is a genuinely good fit and will save you standing up hosting, auth, and a database. If your application has a spine that runs whether or not anyone is looking at it, that spine stays where it is, and Fabric Apps changes where your frontend is hosted rather than what your system is made of.

What a Custom Web App Gives You Instead

Quick answer: Roughly four Azure services and the operational work of owning them — in exchange for everything on the "not documented" side of that table, plus a GA-level SLA and any region you like.

A comparison is only useful if both sides are priced, so here is the thing Fabric Apps is being compared to. Build the same application yourself on Azure and the shape is familiar:

What that buys you is precisely the column Fabric Apps leaves blank: continuous ingestion, scheduled jobs, always-on evaluation loops, server-push to connected browsers. Plus composite primary keys, native many-to-many, stored procedures, direct SQL, non-Microsoft identity providers, a published SLA you can put in a contract, and deployment into any region Azure offers rather than the subset where a preview workload has landed.

What it costs you is the part teams routinely underestimate: you now own the hosting, the auth wiring, the database, the CI/CD, the patching, the certificate renewals, the monitoring, and the person who gets paged. For a genuinely small internal tool that overhead can exceed the value of the tool — which is exactly the gap Fabric Apps is aimed at, and why "we'd just build it ourselves" is not automatically the cheaper answer.

This is not a like-for-like contest. Fabric Apps trades control and always-on capability for almost no setup; a custom build trades setup and ownership for the ability to do anything. The question is which set of constraints your application can live inside.

Fabric Apps Preview Limitations

Quick answer: The documented constraints are specific, and several of them land on data modelling decisions you make in week one rather than problems you hit in month six.

From Microsoft's FAQ and troubleshooting pages, as of 18 October 2026:

• No composite primary keys. Entities use a single UUID id.
• No many-to-many relationships. You model an explicit join entity instead.
• No raw SQL from the application. The FAQ says Fabric Apps "doesn't expose raw custom SQL through its generated API or connectors." The portal shows a connection string and a query editor for the app's database, but that copy is read-only, and Microsoft warns that schema changed directly in SQL "can break the app."
• Column renames, type changes and removals break the app. Adding a column is supported.
• No custom authentication providers beyond Entra SSO and email/password.
• Email and password authentication "doesn't work after deploying to Fabric." Microsoft's wording, not a paraphrase.
• No count() on the fluent GraphQL client — use results.length.
• 100 MB compressed limit on static deployment size.
• No multi-environment management out of the box.
• No ALM, workspace outbound access protection or private links "at this time."

The first two are the ones that hurt. Single-column UUID keys and no native many-to-many are fine if you're greenfield and hear about them on day one. They are expensive if you've modelled a schema around composite keys and discover the constraint after you've written the data layer.

I also could not find a Fabric-Apps-specific service level agreement on any of its documentation pages. The standard Microsoft preview terms apply by reference. For an internal tool that's fine. For anything a regulated buyer will run operations on, "public preview, no product-specific SLA, no published GA date" is the sentence that ends the conversation — and it should, because a preview's limits can move.

Fabric Apps Region Availability in the Gulf

Quick answer: Fabric App (preview) is regionally patchy, and the Middle East picture in particular is worth checking before you design around it.

Microsoft's region availability page, dated 25 September 2026, lists unavailable features per region. Fabric App (preview) is named as unavailable in 18 of them, including UK South, UK West, Canada Central, Spain Central, Poland Central, Switzerland West, Japan West, and Israel Central. East US, East US 2, North Europe and Germany West Central, excluded in July, no longer are. The page ties availability to the tenant's home region and suggests a capacity in a supported region as the workaround.

For teams deploying in the Gulf, three specifics matter:

• UAE Central and Qatar Central are Power BI–only regions. The wider Fabric platform isn't present there at all, so the question of Fabric Apps doesn't arise.
• Israel Central runs full Fabric but excludes Fabric App (preview) by name.
• Saudi Arabia has no Fabric region today and does not appear in the region table. Microsoft has announced (31 August 2026) that its Saudi Arabia East Azure region opens to customers in November 2026, but no Microsoft source yet says which Fabric workloads, Fabric Apps included, it will carry. Plan for today's map.

UAE North is not flagged as excluding Fabric App (preview), and we have Fabric Apps deployed and running there, on hosting URLs that carry the region in the hostname. That is firsthand rather than inferred.

The region page enumerates only exceptions and never says a blank entry means available. For any region you haven't deployed into yourself, treat a blank entry as not excluded rather than confirmed available, and confirm before you commit a design to it.

This is the constraint that catches GCC teams most often, and it's the same shape as the data residency questions that drive Power BI architecture here: the feature exists, the region doesn't, and the gap between those two facts is where a delivery date goes.

Fabric Apps Licensing: Do You Need Power BI Pro?

Quick answer: Not on Fabric capacity. A Fabric App is a non-Power BI Fabric item, which free-licence users can create and share on any F or Trial capacity; the F64 viewer threshold covers Power BI content. Microsoft also announced on 28 September 2026 that Pro and PPU customers will get Fabric Apps at no extra cost, up to 1 GB per app.

This is the point most often got wrong in architecture reviews, usually in the direction of overestimating cost. The reasoning goes: users open it through Fabric, Fabric viewer economics require F64 or a Pro licence per head, therefore every operational user needs a paid seat. That chain breaks at the second link.

The F64 free-viewer rule governs Power BI content. A Fabric App is not Power BI content. Per Microsoft's licensing documentation, users on a free Fabric licence can create and share non-Power BI Fabric items, provided the workspace sits on Fabric or Trial capacity. The Fabric Apps pages state no separate viewer licence. If you want the crossover maths for the Power BI side of your estate, that's a separate calculation entirely.

What you do need:

1. The workspace on assigned Fabric capacity.
2. A tenant administrator to enable the Fabric Apps workload — it's off until someone turns it on.
3. "Run and interact" permission on the item for each user. All workspace members get this by default.
4. Every user able to sign in to Fabric via Entra.

That last point is the real coupling, and it's an organisational cost rather than a licensing one. Your operational users need identities in the Fabric tenant and a sign-in that routes through it. For a team already inside Microsoft 365 that's a non-event. For contractors, field staff, or an external agency, it's a provisioning conversation, and it's worth having before you promise anyone a go-live date.

The other change came at FabCon Europe 2026. Microsoft's 28 September 2026 announcement says Pro and PPU customers get Fabric Apps and Fabric Database capabilities "at no additional cost", up to 1 GB per app, with preview "in the coming weeks". As of 18 October 2026 the Learn licensing and pricing pages do not reflect it yet.

When to Use Fabric Apps vs a Custom Web App

Quick answer: When your application is a governed interface over data that already lives in Fabric, and its failure mode is an inconvenience rather than an incident.

Three cases where it earns its place today:

• Internal tools around your data estate. Reference-data editors, configuration screens, small approval workflows. These are exactly the applications nobody wants to build because standing up hosting, auth, and a database costs more than the tool is worth. Fabric Apps removes that overhead.
• Data-entry surfaces feeding the analytics you already run. Manual adjustments, forecast overrides, mapping tables — the spreadsheets that quietly became production systems.
• Prototypes that need real auth. Anything where you'd otherwise fake sign-in to demo a concept.

And the cases to keep out of it, for now: anything with an always-on requirement, anything a regulator or an operations team depends on while it's in preview without a product-specific SLA, and anything that has to run in a region where the workload isn't listed.

The strategic point is that this decision is cheap to defer and expensive to rush. Fabric Apps is in preview, its limits are documented and moving, and the architecture that keeps your ingestion and always-on components as Azure services can adopt Fabric Apps for the frontend later without a redesign. Adopting it late costs almost nothing. Adopting it early, for a system that needed the pieces it doesn't document, costs the build.

Re-check it quarterly. The preview limitations list is the thing to watch, not the announcement.

Frequently Asked Questions

Q: Is Microsoft Fabric Apps generally available?

No. As of 18 October 2026 it is in public preview. Microsoft's documentation page is titled "What is Fabric Apps (Preview)?" and states "This feature is in preview." It was introduced at Microsoft Build 2026 on 2 June 2026, and the FabCon Europe 2026 additions are also preview. No general availability date has been published, and no Fabric-Apps-specific SLA appears on its documentation.

Q: Can a Fabric App be opened outside the Fabric portal?

Generally yes, and it is worth being precise about which URL you get, because a deployed app has two of them and they are different hosts.

The App backend URL, https://<your-app>-app.rayfin.windows.net/, is the one Microsoft publishes a format for, and it is the base for /api/graphql, /auth, and /storage. The App URL is the one a person actually opens. Microsoft's documentation confirms both properties exist and describes what each is for, but never publishes the App URL's format. In the apps we have deployed it takes the shape https://<name>-<hash>-<region>.webapp.fabricapps.net; a UAE North app resolves to a ...-uaenorth.webapp.fabricapps.net hostname. Fabric SSO is required unless the app is configured for anonymous asset and data access.

Microsoft's data-app template page used to list an exception: apps connected to a Power BI semantic model "can't be opened in their own browser window outside the Fabric portal," described as "a temporary limitation." That line is no longer on the page as of 18 October 2026, and the page gives no further detail, so test the standalone URL before you design around it.

Q: Do users need a Power BI Pro licence to open a Fabric App?

Not on Fabric capacity. A Fabric App is a non-Power BI Fabric item, which free-licence users can create and share when the workspace is on Fabric or Trial capacity, and the F64 threshold for free viewing covers Power BI content. Users do need "Run and interact" permission on the item and the ability to sign in to Fabric through Microsoft Entra. Microsoft also announced on 28 September 2026 that Pro and PPU customers will get Fabric Apps at no additional cost, up to 1 GB per app.

Q: Can Fabric Apps replace a custom web application?

It depends on what the application does besides render an interface. Fabric Apps documents frontend hosting, Entra authentication, a Fabric SQL database behind GraphQL, connectors to Fabric data, and server-side functions that run on request. It does not document background workers, scheduled jobs, persistent connections, or streaming; those terms appear nowhere in its overview or FAQ. If your application is a UI over Fabric-resident data, it can carry the whole thing. If your application has components that run continuously, those stay as Azure services and Fabric Apps changes only where the frontend is hosted.

The custom equivalent is roughly Azure Static Web Apps or App Service, Entra via MSAL, and Azure SQL, plus the work of owning them. Fabric Apps removes nearly all of that setup and gives up always-on execution, non-Microsoft identity providers, composite keys, stored procedures, raw SQL, a published SLA, and regions outside the preview's footprint. Whether that trade works is an application-by-application question, not a platform verdict.

Q: Can a Fabric App write data back to a Power BI semantic model?

No. The semantic model connector offers one operation, executeQuery, which runs DAX and returns a table, so there is no write path to the model itself. Since FabCon Europe 2026, an app can capture overrides, approvals or corrections through a warehouse or SQL database connector, both of which support create, update and delete, or in the default template's managed Fabric SQL database through GraphQL mutations. Decide where writes land before you choose a template.

Q: Is Fabric Apps available in the UAE and Saudi Arabia?

UAE North works: we have Fabric Apps deployed and running there, and it is not listed among the regions that exclude Fabric App (preview) on Microsoft's region availability page, dated 25 September 2026. UAE Central and Qatar Central are Power BI–only regions where the broader Fabric platform isn't available. Saudi Arabia has no Fabric region today; Microsoft has announced its Saudi Arabia East Azure region for November 2026. Because the page enumerates only exceptions and never states that a blank entry means supported, confirm availability with Microsoft before committing an architecture to any region you haven't deployed into yourself.

Q: What is Rayfin?

Rayfin is the open-source TypeScript SDK behind Fabric Apps. It uses decorators such as @entity() and @uuid() to generate a database schema, GraphQL API, and typed client from a single data model definition. It ships as the npm packages @microsoft/rayfin-cli, @microsoft/rayfin-core, and @microsoft/rayfin-client, and its source is public at github.com/microsoft/rayfin.

Deciding where an application ends and analytics begins is the architecture question underneath most Fabric conversations, and it rarely gets settled by a feature list. Beyond The Analytics builds Power BI and Fabric platforms for UAE and Saudi enterprises, including the awkward cases where a dashboard isn't the answer. If you're weighing a build like this, the Fabric versus Power BI decision framework is the companion piece to this one.