Power BI runs in the cloud, but a SCADA historian usually sits on-premises behind a firewall that does not allow inbound connections, so the cloud service cannot simply reach in and query it. The on-premises data gateway is the piece that bridges this gap. It is a small service installed on the plant network that maintains an outbound connection to the Power BI cloud and relays queries down to the local historian and results back up, all without any inbound port ever being opened. This guide explains the reachability problem the gateway solves, how it brokers those outbound connections to power scheduled refresh and DirectQuery, the difference between the personal and enterprise gateway modes, and why a cloud-native SCADA platform can avoid the gateway altogether.
Power BI On-Premises Data Gateway in one line: A Power BI on-premises data gateway is a service installed on a local network that lets the cloud-based Power BI service query an on-premises data source, such as a SCADA historian or a SQL database, without opening any inbound firewall ports. It works by making an outbound connection from inside the network to the Power BI cloud and then relaying queries down to the local source and results back up over that connection, so the plant firewall only ever sees outbound traffic. The gateway powers scheduled refresh and DirectQuery against on-prem data, and it comes in a personal mode for a single user and an enterprise mode for shared, centrally managed use.
The reason a gateway is needed at all comes down to network direction. A SCADA historian or plant database lives inside an operational network protected by a firewall that, quite rightly, does not accept unsolicited inbound connections from the internet. Power BI, meanwhile, runs in the cloud and needs to read from that historian when it refreshes a dataset or serves a live query. If Power BI tried to connect inward to the historian, the firewall would block it, and opening an inbound hole for the cloud service to come through would be a security risk most organisations will not accept. So there is a genuine standoff: the cloud needs the on-prem data, but the on-prem network will not let the cloud reach in.
The gateway resolves this by inverting the direction of the connection. Instead of the cloud reaching in, a gateway service installed inside the plant network reaches out, establishing and holding an outbound connection to the Power BI cloud. Outbound connections are almost always permitted by firewalls because they are how normal internet use works, so no inbound rule and no open port is required. Once that outbound channel is up, the cloud can send a query request down it to the gateway, the gateway runs the query against the local historian on the cloud's behalf, and the results travel back up the same outbound channel. The data flows without the firewall ever having to trust an inbound connection.
This is the core value of the gateway: it makes an on-premises source usable by a cloud service while respecting the network's security posture. From the firewall's point of view nothing unusual is happening, just a local service making an outbound connection, yet from Power BI's point of view the historian behind that firewall is reachable and queryable. That reconciliation of cloud analytics with an on-prem, firewalled data source is exactly the problem the gateway exists to solve, and it is why any team keeping Power BI reports on an on-premises historian ends up deploying one.
Once the gateway is in place, it supports the two ways Power BI gets data from a source. The first is scheduled refresh, used when a report imports its data into the Power BI model. On the refresh timer, the cloud service asks the gateway to pull the current data from the on-prem historian, the gateway runs the query locally and sends the results up, and Power BI loads them into the model. Between refreshes the report runs on that imported copy, so the gateway is only busy at refresh time. For SCADA reporting on pre-aggregated data with a periodic refresh, this is the common pattern, and the gateway is what makes the refresh able to reach the on-prem source at all.
The second is DirectQuery, used when a report queries the source live rather than importing. Here every interaction with the report - each filter, each drill-down - generates a query that the cloud service sends through the gateway to the historian in real time, and the gateway relays the answer back so the report always reflects current data. DirectQuery keeps reports fresh without importing large volumes, which suits high-volume time-series data that would be impractical to load in full, but it puts continuous query load on both the gateway and the historian, so the gateway has to be sized and located to handle that traffic. In both modes the gateway is the conduit; the difference is whether it is used periodically for a refresh or continuously for live queries.
Because the gateway sits on the path of every query to the on-prem source, its reliability and performance directly shape the reports that depend on it. A gateway on an underpowered machine, or one that loses its outbound connection, will make refreshes fail and DirectQuery reports slow or unavailable, even though the historian itself is fine. That is why the gateway is treated as production infrastructure: it needs a stable host, a dependable outbound path to the cloud, and enough capacity for the query load it carries. For a busy SCADA reporting environment, the gateway is not an afterthought but a component that has to be provisioned and maintained like any other part of the reporting stack.
The gateway comes in two forms suited to different needs. The personal mode is designed for a single user refreshing their own reports; it is simple to install and runs under that person's context, but it is not meant to be shared, does not support DirectQuery for shared datasets, and stops working if that user's machine is off. The enterprise mode is the shared, centrally managed option: it runs as a service independent of any one user, supports multiple users and data sources, allows DirectQuery, and is administered centrally with managed credentials and permissions. For any serious SCADA reporting used by a team, the enterprise mode is the right choice, because reporting cannot depend on one person's desktop being switched on.
The enterprise gateway's central management is what makes it viable at scale. Administrators register the on-prem data sources on the gateway once, store the credentials there securely, and grant users permission to build reports on those sources without ever handling the underlying credentials themselves. That separation of source configuration from report authoring is essential in an operational environment, where the historian connection details should be controlled by a few administrators rather than scattered across every analyst's machine. The enterprise gateway thus provides not just reachability but governed, shared, dependable access to the on-prem SCADA data.
It is worth recognising that the gateway exists entirely to work around the fact that the data source is on-premises, and a cloud-native SCADA platform removes that reason. If the historian and its query endpoint are already in the cloud, as they are with a platform such as Merobix, then Power BI can connect to them directly over the internet, with no inbound firewall problem to solve and therefore no gateway to install, host, size, or maintain. The reachability standoff simply does not arise, because the data is already on the same side of the firewall as the cloud analytics. For field operations weighing how to get their SCADA data into Power BI, a cloud SCADA platform can turn a gateway deployment and its ongoing upkeep into a direct connection, which is one fewer piece of infrastructure to run.
It inverts the direction of the connection. Instead of the cloud reaching inward to the on-prem historian, which the firewall would block, the gateway service installed inside the network makes an outbound connection to the Power BI cloud and holds it open. Outbound connections are normally permitted, so no inbound rule or open port is needed. The cloud then sends query requests down that outbound channel, the gateway runs them against the local source, and the results travel back up the same channel, so the firewall only ever sees outbound traffic.
The personal gateway is for a single user refreshing their own reports; it is simple but not shareable, does not support DirectQuery for shared datasets, and stops working when that user's machine is off. The enterprise gateway runs as a shared service independent of any one user, supports multiple users and data sources, allows DirectQuery, and is centrally administered with managed credentials and permissions. For team SCADA reporting the enterprise mode is the right choice, because reporting cannot depend on one person's desktop being switched on.
Yes, if the SCADA data source is already in the cloud. The gateway exists purely to let cloud Power BI reach an on-premises source behind a firewall, so if the historian and its query endpoint are cloud-hosted, as with a cloud-native SCADA platform, Power BI can connect directly over the internet with no inbound firewall problem and no gateway to install or maintain. The reachability standoff never arises because the data is already on the same side of the firewall as the cloud analytics, removing a whole piece of infrastructure.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.