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
How the Power BI on-premises data gateway works, when UAE & Saudi enterprises need it, and how to configure it for residency, HA, and compliance.
Co-authored by
Quick answer: The Power BI on-premises data gateway is software installed on a server within your network that creates a secure, outbound-only bridge between on-premises data sources and the Power BI cloud service — without requiring inbound firewall ports or exposing internal databases to the internet.
The gateway solves a specific architectural problem: your data lives inside your network, but Power BI runs in the cloud. Rather than replicating entire databases to Azure, the gateway sits between the two environments and relays only the query results that Power BI needs.
For GCC enterprises — particularly UAE government agencies and Saudi organizations operating under data residency requirements — the gateway is often the critical infrastructure component that makes cloud BI viable. It allows agencies to keep sensitive data behind their own firewalls while delivering interactive dashboards through the Power BI service. For the broader compliance and deployment landscape, our Power BI for GCC government analytics guide covers data residency, licensing, and implementation methodology.
The gateway supports connections to SQL Server, Oracle, SAP HANA, SAP BW, MySQL, PostgreSQL, Teradata, IBM Db2, SharePoint on-premises, and dozens of additional connectors listed in Microsoft's data source documentation. If your organization runs SAP S/4HANA, Oracle E-Business Suite, or on-premises SQL Server data warehouses — the systems that dominate GCC enterprise environments — the gateway is how those sources connect to Power BI without leaving your perimeter.
Quick answer: The gateway initiates all connections outbound over TLS 1.3, uses Azure Relay as an encrypted message broker, and transmits only compressed query results to the cloud — raw data never leaves your network in bulk, and no inbound firewall ports are required.
Understanding the data flow is essential for any GCC security or compliance review. Here is what happens when a user opens a Power BI report connected to an on-premises data source:
The critical security property: raw source data is never bulk-transferred to Azure. For a report visual showing monthly revenue by department, the gateway transmits a handful of aggregated rows — not the millions of transaction records behind them.
The gateway requires only outbound connections:
| Port | Protocol | Purpose |
|---|---|---|
| 443 | HTTPS | Primary communication with Power BI service |
| 5671, 5672 | AMQP | Azure Relay (Service Bus messaging) |
| 9350-9354 | TCP | Azure Relay (legacy, fallback) |
| 80 | HTTP | Certificate validation only |
No inbound ports need to be opened. All traffic uses TLS 1.3 encryption by default. This outbound-only model simplifies firewall approval in GCC government environments where opening inbound ports requires extensive security review cycles.
Quick answer: Standard mode is the only viable option for GCC enterprise deployments — it supports multiple users, DirectQuery, live connections, high-availability clustering, and centralized administration. Personal mode is limited to a single user refreshing Import datasets and has no place in production environments.
| Capability | Standard Mode | Personal Mode |
|---|---|---|
| Multiple users | Yes — shared across the organization | No — single user only |
| DirectQuery and live connections | Yes | No — Import mode only |
| High-availability clustering | Yes — up to 10 nodes | No |
| Centralized administration | Yes — gateway admins manage data sources | No — tied to one account |
| Supported services | Power BI, Power Automate, Power Apps, Azure Analysis Services, Logic Apps | Power BI only |
| Runs as Windows service | Yes — always-on, server-grade | No — interactive application only |
| Load balancing | Yes — distributes queries across cluster members | No |
Personal mode has one legitimate use case: an individual analyst refreshing a few Import datasets from local files, with no requirement to share the data source configuration. Every other scenario — multiple users, DirectQuery, live connections, production workloads — requires standard mode.
For GCC government agencies, standard mode with high-availability clustering is the baseline, not a luxury. Install the standard gateway on a dedicated Windows Server VM with at least 8 GB RAM and 8 CPU cores, placed on the same network segment as your data sources.
Quick answer: Scheduled refresh imports a full data snapshot at defined intervals, while DirectQuery sends individual queries to the on-premises source in real time — each approach has different gateway resource implications and data freshness characteristics.
Power BI pulls a complete copy of the data into its in-memory VertiPaq engine during each scheduled refresh. The gateway executes the import query, compresses the result, and transmits it to the Power BI service.
No data is imported. Every user interaction — filter change, drill-down, page navigation — generates a live query that the gateway forwards to the on-premises source in real time.
Microsoft's gateway sizing guidance recommends separating Import and DirectQuery workloads onto different gateway clusters. Import refreshes consume RAM; DirectQuery consumes CPU. Running both on the same cluster risks refresh jobs degrading interactive query performance.
For GCC deployments connecting to SAP HANA or Oracle through DirectQuery, gateway placement matters: install the gateway as close to the data source as possible on the network. If SAP runs in a co-located data center in Dubai, the gateway should be there — not in a remote office connected by VPN.
Quick answer: A gateway cluster consists of two or more gateway installations sharing the same configuration, providing automatic failover and optional load balancing — Microsoft supports up to 10 nodes per cluster, and a minimum of two nodes is the baseline for any production GCC deployment.
Quick answer: Use the on-premises data gateway when your organization uses the Power BI cloud service but needs access to on-premises data sources. Use Power BI Report Server (PBIRS) when regulatory requirements mandate a fully on-premises BI platform where no data or metadata reaches the cloud.
These are complementary tools, not competitors, but GCC organizations frequently conflate them.
| Criteria | On-Premises Data Gateway | Power BI Report Server (PBIRS) |
|---|---|---|
| Primary purpose | Secure bridge to the Power BI cloud service | Fully on-premises reporting portal |
| Where reports live | Power BI service (cloud) | PBIRS server (on-premises) |
| What crosses the wire | Compressed, encrypted query results | Nothing leaves the network |
| Cloud dependency | Yes | No — fully self-contained |
| AI and Copilot features | Yes — full Power BI service capabilities | No — limited feature set |
| High availability | Gateway clustering (up to 10 nodes) | SQL Server Always On |
Choose the gateway when the compliance concern is about where source data resides, not whether metadata reaches the cloud. The gateway ensures raw data stays on-premises while only query results traverse the encrypted channel.
Choose PBIRS when the requirement is absolute air-gap isolation — no data, no metadata, no query telemetry can leave the network. This is common in defense, intelligence, and certain critical infrastructure environments across the GCC.
Hybrid deployments are common. An agency might run PBIRS for classified datasets while using the gateway-connected cloud service for operational dashboards — with data classification boundaries governing which reports live where.
Quick answer: The gateway keeps raw data within your network perimeter while transmitting only encrypted query results to the Power BI service hosted in Azure UAE North — satisfying UAE PDPL data minimization principles and providing Saudi organizations with an interim architecture until the Saudi Arabia East Azure region launches in Q4 2026.
For UAE organizations, the Azure UAE North region (Dubai) provides in-country data residency for the Power BI service. When configured for UAE North:
This aligns with the UAE PDPL (Federal Decree-Law No. 45 of 2021). While the Executive Regulations have not yet been published as of early 2026, the technical configuration should be in place proactively — organizations will have six months to comply once regulations are issued.
For agencies subject to NESA Information Assurance Standards, the gateway's outbound-only, TLS 1.3 architecture maps to NESA's network security and data-in-transit controls without requiring inbound firewall exceptions.
Microsoft confirmed in February 2026 that the Saudi Arabia East Azure region (Eastern Province, three availability zones) will go live in Q4 2026. Until then, Saudi agencies have two interim options.
Option 1: Gateway + UAE North with contractual safeguards. The gateway keeps raw data within Saudi borders — only compressed query results cross to UAE North. Supplement with contractual data handling agreements addressing NDMO's National Data Governance Framework requirements for cross-border transfer. This is the most common interim approach.
Option 2: Fully on-premises with PBIRS. For data classified under SDAIA's framework where no query results can leave Saudi borders, PBIRS provides a fully air-gapped deployment at the cost of reduced cloud features.
Post-Q4 2026 migration: Once Saudi Arabia East is live, organizations on Option 1 can migrate their Power BI tenant to the Saudi region. The gateway configuration itself does not change — only the Azure region that the gateway connects to shifts. The gateway's outbound connection targets update automatically when the tenant region changes.
Quick answer: Install the standard gateway on a dedicated Windows Server 2019+ VM, use a dedicated domain service account, verify outbound connectivity to Azure Relay, add data sources through the Power BI Admin Portal, and enable audit logging through Microsoft Purview before going to production.
No. The gateway executes queries locally against your on-premises data sources and transmits only compressed, encrypted query results to the Power BI service through Azure Relay. For a dashboard visual showing aggregated revenue by region, the gateway sends a few dozen rows of aggregated output — not the underlying transaction tables. Raw source data never leaves your network. Credentials are encrypted with asymmetric encryption and only decrypted on the gateway machine itself.
The gateway requires outbound access on TCP ports 443 (HTTPS to Power BI service), 5671 and 5672 (AMQP for Azure Relay), 9350-9354 (Azure Relay fallback), and port 80 (HTTP for certificate validation). No inbound ports need to be opened. All communication is initiated outbound by the gateway.
Yes, but Microsoft recommends using separate gateway clusters for each workload type. Scheduled refresh is RAM-intensive (the full dataset is loaded into memory during transfer) while DirectQuery is CPU-intensive (every user interaction generates a live query). Running both on the same cluster risks refresh jobs degrading interactive query performance.
A minimum of two nodes per cluster for production workloads, with Microsoft supporting up to 10 nodes. Two nodes provide basic failover; three nodes are recommended for environments that require maintenance windows without reduced redundancy. All nodes must run the same gateway version.
Yes. The gateway supports DirectQuery and Import connections to SAP HANA, SAP BW, SAP NetWeaver, Oracle Database, and dozens of other enterprise sources. For SAP, the gateway supports Single Sign-On via Kerberos or SAML, enabling row-level security enforcement based on SAP authorization objects. Oracle connections require Oracle Data Access Components (ODAC) on the gateway server. Place the gateway on the same network segment as the database to minimize query latency.
The gateway's architecture aligns with UAE data protection requirements when configured correctly. Its outbound-only communication model, TLS 1.3 encryption, and Azure Relay's managed certificate infrastructure map to NESA Information Assurance Standards for network security and data-in-transit protection. For PDPL compliance, ensure your Power BI tenant is set to Azure UAE North so query results remain within UAE borders. The gateway itself runs within your network perimeter, so source data residency is inherently maintained.
Until Saudi Arabia East launches in Q4 2026, Saudi organizations typically deploy a gateway within their Saudi network connected to a Power BI tenant in Azure UAE North. Raw data stays in Saudi Arabia — only compressed query results cross to UAE North, supplemented with contractual data handling agreements addressing NDMO and SDAIA cross-border requirements. For the highest sensitivity levels, Power BI Report Server provides a fully air-gapped alternative. Once Saudi Arabia East is live, the tenant region can be migrated without changing the gateway configuration.
Microsoft releases monthly gateway updates with security patches, performance improvements, and new connector support. Apply updates within 30 days of release. In a clustered environment, update one node at a time to maintain availability. Monitor the monthly release notes for breaking changes affecting your data source connectors.
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
Topics