Insightsfrom the team
Power BI deep-dives, migration playbooks, and data strategy for enterprise teams.
Ready to unlock your data's potential?
Join dozens of organizations who have moved to Beyond The Analytics. Book your personalized demo today
See your company like never before
Power BI deep-dives, migration playbooks, and data strategy for enterprise teams.
Join dozens of organizations who have moved to Beyond The Analytics. Book your personalized demo today
Fabric Apps read a semantic model through an API capped at 120 queries per minute per user. Refresh floors, a latency budget by leg, and the faster path.
Co-authored by
Quick answer: A Fabric App built from the data-app template reads through the Execute Queries REST API, capped at 120 query requests per minute per user. As of August 2026 Microsoft documents no push or subscription mechanism in the Fabric Apps item type, so "live" means polling, and the polling rate is the ceiling.
This is about Fabric Apps, the item type — in public preview since Build 2026, scaffolded with the Rayfin SDK — and specifically its dataapp template — one of four distinct things people mean by "Fabric apps". It is not about Real-Time Intelligence, a separate set of Fabric items that genuinely does move data in seconds. That distinction is the whole post. Microsoft Fabric can carry real-time data. The Fabric Apps item type gives you none of the mechanisms that do it.
The boundary itself is settled. The component-by-component comparison against a custom web app established that Microsoft documents no WebSocket, SSE, background worker, cron or always-on primitive anywhere in the Fabric Apps overview or FAQ. What it did not do is price the alternative: if polling is all you have, how fresh can the screen be, and what does each second cost? Every figure below comes from Microsoft Learn, and where Microsoft publishes no number that is stated as a finding rather than filled in.
Quick answer: Execute Queries is limited to 120 query requests per minute per user regardless of which semantic model is queried, so a ten-visual app cannot refresh faster than once every five seconds.
Microsoft's Execute Queries reference says it plainly: "There's a limit of 120 query requests per minute per user, regardless of the dataset that's queried."
Two phrases decide an architecture. Per user: not per app, not per session, not per capacity, so the same person watching on a desk monitor and a wall display draws both from one allowance. Regardless of the dataset: splitting visuals across three semantic models to spread the load does not work, because the cap follows the identity.
The API allows one query per call and returns one table per query, so each visual needing its own figure needs its own request. A ten-panel operations screen works out like this:
Five seconds is a floor reached only if every request returns instantly and nothing else on that account touches the API. A second open window makes it ten. Nothing in the calculation involves data volume, model size or capacity SKU, so you hit it while the numbers on screen are still trivially small. The same reference caps each query at 100,000 rows, 1,000,000 values and 15 MB.
One constraint closes a design pattern outright: service principals are not supported for models with row-level security enabled. The obvious workaround is a single service identity fetching once and fanning results out to viewers, sidestepping the per-user cap. With RLS on, that route is shut. Every user polls as themselves.
Quick answer: The Fabric API for GraphQL supports queries and mutations only. As of August 2026 Microsoft documents no subscription support, so there is no server-initiated push over that endpoint.
Subscriptions are the standard way a browser receives data it did not ask for — one long-lived connection, updates sent as they happen — and they are what most people mean by "live". Microsoft's Fabric API for GraphQL FAQ is direct: "Only GraphQL queries (read) and mutations (write) are supported currently." The published limits, updated 4 August 2026, describe a request/response API and nothing else: default page size 100, maximum pagination 100,000 items, maximum response 64 MB, request timeout 100 seconds, maximum query depth 10.
Two endpoints share the word GraphQL and must not be merged. The above is the standalone Fabric API for GraphQL item. The endpoint Rayfin generates inside a Fabric App at /api/graphql is a different service, and Microsoft documents subscription support there neither way — neither supported nor excluded. Anyone asserting that a Fabric App supports GraphQL subscriptions is generalising from the standalone item; anyone asserting it definitively cannot is doing the same in reverse. As of August 2026 it is undocumented, and an undocumented capability does not belong in a design.
Quick answer: The dominant leg is not the one teams suspect. Eventhouse to OneLake availability defaults to a write delay of up to three hours, larger than every other documented figure here by a wide margin, and larger than the seconds-scale legs by three orders of magnitude.
Freshness on screen is the sum of every hop, and teams almost always budget only for the last one.
| Leg | Documented figure | What it means |
|---|---|---|
| Eventhouse to OneLake write delay | Up to 3 hours by default (TargetLatencyInMinutes, range 5 minutes to 3 hours) | Anything reading the OneLake copy rather than the Eventhouse inherits this |
| Eventstream ingestion | No latency figure documented | The only observable is a watermark-delay metric measured in seconds. Max message 1 MB, retention 90 days, at-least-once delivery |
| Eventhouse streaming ingestion | "latency of less than a few seconds" | A scenario criterion, not an SLA. On by default for Fabric tables |
| Eventhouse queued ingestion | 5 minutes, 500 items or 1 GB, whichever triggers first; configurable 10 seconds to 30 minutes | The 5 minutes is a ceiling on an idle table, not typical latency |
| Eventhouse compute availability | "available compute for your analytics within 5 to 10 seconds" | Applies before a query runs |
| Eventhouse cold start | "a latency of a few seconds" on reactivation | Eventhouses suspend when idle; overnight boards pay this first thing |
| Direct Lake framing | "takes only a few seconds" | The metadata operation, not end-to-end freshness. Conflating them is the commonest error in third-party writing |
| DirectQuery | No documented latency | Defers to the source. Microsoft's targets: 5 seconds or under good, over 30 seconds "unacceptably poor". Timeout 4 minutes, 1,000,000-row limit |
| Execute Queries poll | 120 requests per minute per user | 5-second floor on a ten-visual app |
Four notes on reading that table.
Never add the numbers up. Microsoft publishes no end-to-end total for any of these paths, and a sum of components measured under different conditions is a fabricated figure with citations attached.
Batching is 500 items, not 1,000. The older Azure Data Explorer ingestion FAQ still says 1,000 blobs, and that is the page most third-party blogs copied. Cite the current batching policy page.
Lowering batching values can increase latency. Microsoft warns about this explicitly. Tuning the policy down as a reflex is how teams make a system slower while believing they optimised it.
Direct Lake freshness is not framing speed. Data is served "at the point of the most recent successful framing operation. That time isn't necessarily the latest state of the Delta tables." Automatic updates are on by default, and their interval is documented only as "periodically". The official term is framing, not reframing.
Quick answer: Fabric documents three genuine fast paths — Eventstream custom endpoints, the pollable KQL REST API, and Fabric Embedded for Real-Time Dashboards. The data-app template wires up none of them.
Eventstream custom endpoints. The custom app destination documentation states that "you can consume real-time events from the eventstream to your own application," over Event Hub, AMQP 1.0 or Kafka. The connection string "works with the Azure Event Hubs SDK", authenticated by SAS key or Entra ID. A genuine push path into application code.
The KQL query REST API is pollable directly. A POST to /v2/rest/query with a bearer token and a body carrying csl and db returns Eventhouse results with no semantic model in the path, and the reference is marked as applying to Microsoft Fabric. Querying the Eventhouse rather than a model layered on top of it removes framing, Direct Lake update intervals and the OneLake write delay from the budget in one move — the practical version of the architecture in the Fabric real-time analytics walkthrough.
Fabric Embedded carries a Real-Time Dashboard into a web application while Fabric keeps enforcing authentication and permissions. Read that wording carefully: Microsoft documents it for "your own web application" generically, and the Fabric Apps documentation set never mentions embedding. Do not assume the two compose.
None of the three is wired into the data-app template, which does semantic-model DAX through Execute Queries and stops. The question is therefore not whether Fabric can go faster but whether app code can reach any of it. The KQL REST API accepts any Entra-authenticated caller, so it is technically callable from a Fabric App frontend, but Microsoft documents no template support and says only "coming soon" about wider data source coverage. That is the exact shape of the answer, and not something to hang a delivery date on.
Quick answer: A Fabric App connected to a semantic model cannot be opened in its own browser window outside the Fabric portal, and selecting Open makes the visual queries error out. That rules out unattended operations displays.
The limitation appears in Microsoft's documentation as a line item, and it is almost never connected to the use case it destroys. An operations command centre is usually a wall-mounted screen running unattended, and the build for that is a browser in kiosk mode on a fixed URL. A data-app-template Fabric App cannot be that: it functions only inside the Fabric portal, behind an interactive sign-in, in a session that expires. Microsoft calls this "a temporary limitation, and will be addressed in a future release" — quoted in full alongside the app's two URL formats in the component-by-component comparison — which is a plan rather than a capability.
The useful question then is not how to work around it but whether the surface was ever right. The one rule for where a feature lives settles that in a sentence: if a user acts on it, or needs it within seconds, it belongs in the application. A live operations board is a read within seconds, which puts it on the application side of the line, and a data-app-template Fabric App is not that application. The polling floor and the portal constraint are two faces of one design decision.
Quick answer: Polling is interactive load, and Fabric smooths interactive operations over a 10-minute window rather than the 24-hour window that hides background work.
Fabric smooths interactive operations over 10 minutes and background operations over 24 hours. A nightly refresh spreads its cost across a day. A screen polling every five seconds is interactive load concentrated into ten-minute buckets, all day, every day it is switched on. Overage protection sits at roughly 3× purchased CUs, so there is headroom, but headroom that is permanently occupied is not headroom.
Microsoft makes the related point about Real-Time Dashboard live refresh: its detection queries consume capacity even when nothing has changed. The same logic governs any polled surface — a quiet overnight shift costs very nearly what a busy one costs, because the rate is set by the clock rather than the data. Size for the steady state — a screen running continuously is a baseline, not a peak, which changes the SKU conversation that Fabric capacity sizing works through.
Quick answer: Real-Time Dashboards reached GA in July 2026 with live refresh GA in June 2026, and are the right surface for read-only monitoring on Fabric data. Fabric Apps suit governed interfaces at human speed. Server-initiated push needs an Eventstream custom endpoint and application code.
Fabric App (dataapp) | Real-Time Dashboard | Custom app on Eventstream | |
|---|---|---|---|
| Data path | Semantic model via Execute Queries | Eventhouse / KQL directly | Event Hub, AMQP 1.0 or Kafka |
| Refresh mechanism | Client polling only | Live refresh, high-water-mark checks | Push from the stream |
| Documented rate limit | 120 requests/min/user | No documented floor for either author knob | Governed by your own code |
| Runs outside the Fabric portal | No (documented limitation) | Yes, via Fabric Embedded | Yes |
| Server push | Not documented | Not applicable | Yes, natively |
| Write-back | No (Execute Queries is read-only) | No | Yes |
Real-Time Dashboards. Microsoft's what's new page records dashboard GA in July 2026 and live refresh GA in June 2026. The mechanism is "a single lightweight background query per visual based on the ingestion_time() function", with the dashboard periodically checking each visual's high-water mark. Authors get a refresh rate limit and a fallback refresh interval, and Microsoft publishes no values or floors for either, so any quoted minimum refresh interval for a Fabric Real-Time Dashboard is not coming from the documentation. Fabric also no longer uses the older model where an author sets a floor and viewers pick a rate; that still exists in Azure Data Explorer dashboards, not Fabric.
Power BI reports. Automatic page refresh reaches a one-second minimum only on dedicated capacity with DirectQuery. Change detection defaults to 5 seconds, not five minutes — Microsoft's implementation-planning guidance contradicts its own product documentation here, and the automatic page refresh page is the one to trust.
Activator, for alerting rather than display. Eventstream rules are documented as "optimized for subsecond decisioning latency after event arrival", while the same documentation set says "in some cases, it can be up to 10 minutes." Both belong in a design conversation. Backend processing adds up to 1 minute, late-arrival tolerance defaults to 2 minutes and floors any rule that uses it, and rules driven by a Power BI visual are queried once per hour by default.
It can display recent data refreshed by polling, with a practical floor around five seconds for a ten-visual app. It cannot receive pushed updates. As of August 2026 the Fabric Apps documentation describes no WebSocket, server-sent events, background worker or subscription mechanism, and the data-app template reads exclusively through the Execute Queries REST API.
The binding limit is 120 query requests per minute per user, applied regardless of which dataset is queried. Divide 120 by the number of visuals to get cycles per minute: ten visuals gives twelve cycles, or one refresh every five seconds. Two open copies under the same identity halve that, because the cap is per user rather than per app or per model.
The standalone Fabric API for GraphQL does not — Microsoft's FAQ states that "only GraphQL queries (read) and mutations (write) are supported currently." The separate endpoint that Rayfin generates inside a Fabric App is undocumented on this point in both directions, so treat it as unavailable for design purposes until Microsoft publishes an answer.
Microsoft documents no template support for it. The KQL query REST API accepts any Entra-authenticated caller, so calling it from Fabric App frontend code is technically possible, and Microsoft's material says only "coming soon" about wider data source coverage. That is a fair basis for a prototype and a poor basis for a delivery commitment.
Apps connected to a Power BI semantic model "can't be opened in their own browser window outside the Fabric portal," and Microsoft's documentation states that selecting the Open button results in the visual queries erroring out. Microsoft calls it "a temporary limitation, and will be addressed in a future release." It rules out kiosk-mode wall displays and unattended screens generally, because those depend on a standalone URL that keeps working without an interactive portal session.
Microsoft publishes no product floor. Authors set a refresh rate limit and a fallback refresh interval, and neither has documented values or minimums as of August 2026. A minInterval value visible in exported dashboard JSON is part of a sample payload, not a specification. If a specific interval matters contractually, get it confirmed by Microsoft in writing rather than inferred from an export.
Microsoft does not document this case, and it is the most commercially significant open question about the data-app template. The general position is settled: a Fabric App is a non-Power BI item, so per Microsoft's licensing documentation a free Fabric licence opens one provided the workspace sits on Fabric or Trial capacity — the full reasoning is worked through here. What is undocumented is whether querying a semantic model through Execute Queries reintroduces a per-viewer Power BI requirement. On a hundred-seat rollout the answer either costs nothing or adds a paid seat for every one of those users, and the documentation will not tell you which. Ask your Microsoft account team before you budget it.
Real-time requirements are where architecture decisions stop being reversible, because the surface you pick determines which mechanisms you can reach rather than just where the code is hosted. Beyond The Analytics builds Power BI and Fabric platforms for UAE and Saudi enterprises, including the operational cases where a dashboard turns out not to be the answer.
Microsoft Partner · Dubai
Your business intelligence partner for the GCC
Have a data challenge or a project in mind? Reach out and let's explore how we can help.
Clients we've worked with
