When does a Power BI scheduled refresh require an on-premises data gateway?

## Why a gateway exists at all The Power BI Service is a multi-tenant cloud service. When a scheduled refresh fires, the refresh job runs in Microsoft's datacentre and has to reach your data from there. If the source has a public endpoint the Service can call — SharePoint Online, OneDrive for Business, Dataverse, Azure SQL Database or Synapse with public network access, Snowflake, most SaaS connectors — no extra component is needed; the Service connects directly using the credentials stored on the semantic model. If the source lives inside your network, there is no route. Opening an inbound firewall hole to a cloud service is not acceptable, so Microsoft's answer is the **on-premises data gateway**: software you install on a machine *inside* the network, which opens an **outbound** connection to the Service (Azure Service Bus / Relay) and holds it open. Refresh jobs are handed down that channel, executed against the local source by the gateway, and the results are pushed back up encrypted. No inbound port is opened. ## The rule of thumb Ask one question: *can a machine in Microsoft's cloud reach this endpoint on its own?* If yes, no gateway. If no, gateway. The trap is that "cloud source" is not the same as "reachable". An Azure SQL Database configured with a private endpoint and public access disabled is a cloud source that still needs a gateway (or a VNet data gateway, the managed variant that lives inside your Azure virtual network rather than on a VM you patch). The other trap runs the opposite way: a file on the analyst's laptop, or a UNC path to a departmental share, is an on-premises source even though nobody thinks of it as a "server". A model built on `C:\Users\me\sales.xlsx` will refresh happily in Desktop and fail on every schedule in the Service. ## Standard mode versus personal mode These are two installation modes of the same download and they are not equivalent. **Standard mode** ("on-premises data gateway"): installed as a Windows service on a server, registered to the tenant, administered by gateway admins who define *data source* connections on it and grant users the right to bind semantic models to those connections. It supports scheduled **import** refresh, **DirectQuery** and **live** connections, and is used by Power Apps, Power Automate and Azure Analysis Services as well. Multiple gateway installations can be joined into a **cluster** so a single node going down does not stop refresh, and so load spreads across nodes. **Personal mode** ("on-premises data gateway (personal mode)"): installed on an individual's machine, usable only by that person, no shared data source administration, and — the decisive limitation — **import refresh only**. No DirectQuery, no live connection. If the laptop is asleep, hibernating or off the VPN when the schedule fires, the refresh fails. It exists so a single analyst can prototype, and it is a recurring production incident when someone quietly relies on it. ## What refresh needs besides connectivity A gateway solves reachability, not authorisation. Refresh also requires that credentials be stored on the semantic model (or on the gateway data source) and that they still be valid — OAuth tokens for cloud sources expire and must be re-signed-in, which is a classic "it worked for three weeks then broke" failure. Privacy levels configured on the data sources also matter: incompatible privacy levels can block a query that combines two sources, failing refresh with a data-privacy/firewall error even though both sources are reachable. ## DirectQuery and live are not exempt People sometimes assume the gateway is a refresh-only concern. It is not. A DirectQuery model over on-premises SQL Server sends *every user interaction* through the gateway at query time, and a live connection to an on-premises Analysis Services model does the same. That makes gateway sizing, placement (close to the data source, on a machine with good network and CPU) and clustering an interactive-performance concern, not just a nightly-batch one — and it is why personal mode, which cannot do DirectQuery at all, is disqualifying for those models. ## Refresh frequency and capacity Scheduled refresh frequency is capped, and the cap depends on the capacity the workspace sits in: workspaces on shared capacity have long been limited to a small number of scheduled refreshes per day (documented as eight), while dedicated/Premium-style capacity allows substantially more (documented as forty-eight) and additionally exposes the XMLA endpoint, which lets external tools trigger refresh programmatically. These numbers have moved with the platform's licensing generations, so state the shape of the rule in an interview and check the current documentation before you design to a number. Either way, the gateway itself is not the limiter — the capacity is. ## Answer shape "Gateway when the Service can't reach the source: on-prem or private-network. Standard mode for anything shared or DirectQuery, clustered for availability, sited near the source. Personal mode is import-only and single-user, so it's a prototype tool. And remember reachability isn't the only failure mode — expired credentials and privacy levels break refresh with the gateway working fine."