Almanac
Microsoft/power-biPower Platform

Consultant KB for Microsoft Power BI: semantic models, DAX and modelling, Power Query and dataflows, reports and visuals, the service and workspaces, capacity and performance, embedding and integration, governance and security, ALM and deployment, and licensing, plus cross-cutting decision guides. Scoped to Power BI, with Microsoft Fabric covered where it touches Power BI directly. Implementation notes, configuration decisions and the gotchas that bite on real projects. Populated by the daily author agent from the Power BI release plans, docs repo and product blog, plus the author's own consultant notes.

power-bi/03-power-query-and-dataflows/feature-data-gateways.md
feature-data-gateways.mdv1 · history
CurrentApplies to BothUpdated last monthSource Microsoft Learn ↗

What it does

The on-premises data gateway is a Windows service installed inside the client's network that lets Power BI in the cloud query data that isn't reachable from the internet. It polls outbound to Azure and receives work in the responses, so no inbound firewall ports are needed.

Key facts

  • Three flavours: the standard on-premises data gateway (multiple users, multiple sources, shared), personal mode (one user, Power BI only, not shareable), and the virtual network (VNet) data gateway, which is a Microsoft-managed service with nothing to install.
  • One standard gateway installation serves every supported service — Power BI, Fabric, Power Apps, Power Automate, Logic Apps, Azure Data Factory, Azure Analysis Services.
  • Microsoft supports only the last six monthly releases. A new gateway update ships every month.
  • Power BI DirectQuery through the gateway has a 16 MB uncompressed data response limit.
  • There's a limit of 1,000 data sources per enterprise or personal gateway cluster.
  • Credentials are cached client-side on the gateway. The cache expires in hours — Microsoft's example is that changed credentials may not take effect for around five hours, and connections fail in the meantime.
  • With a standard gateway, data source credentials are held by the gateway admin against the data source, so report owners don't enter them. With personal mode, the owner supplies them.

When to use / skip

If the source lives on-premises or behind a private network, you need a gateway and there's no negotiation. The real decision is standard versus personal: personal mode is fine for one analyst's own work and completely unsuitable for anything a business depends on, because it dies with the user's machine and account. Use the VNet gateway when the data is in Azure behind a virtual network — it removes a server, a patching obligation and an on-call escalation from the client's plate. Never let personal mode become the production answer by accident, which is exactly how it usually happens.

Configuration decisions

  • Standard, personal or VNet — decided by where the data actually sits and who depends on it.
  • Cluster membership and node count. A cluster of at least two gives you failover and lets you patch without an outage window.
  • Which server the gateway runs on and how close it sits to the data sources. Gateway-to-source latency is what you're managing, not gateway-to-cloud.
  • Which service account runs the gateway service, and whether that account survives password rotation policy.
  • Who the gateway admins are, and which data sources each report team is granted use of.
  • Whether the monthly update gets applied on a schedule or only when something breaks — the six-release support window makes this a real decision.

Gotchas

  • A single-node gateway is a single point of failure for every refresh in the tenant. Clients discover this during a Windows Update reboot at 3am.
  • The credential cache means "I've updated the password" and "refresh works again" can be hours apart. Don't spend that time debugging something else.
  • Gateway sizing failures look like refresh failures. Concurrent refreshes on one under-specified box queue and time out, and the error blames the data source.
  • Personal mode gateways are invisible to IT until the person who installed one leaves the organisation.
  • Falling more than six releases behind puts you outside support, and gateway issues are exactly where you'll want support.

Consultant notes

  • Get the gateway into the infrastructure conversation early. It needs a server, a service account, firewall review and an owner — none of which appear in a Power BI project plan by default.
  • Always argue for a cluster. The cost is one more VM and the alternative is explaining an all-day refresh outage.
  • Agree a patching rhythm with the client's infrastructure team and write it into the handover. Monthly releases plus a six-release support window means this can't be nobody's job.
  • Make gateway admin a named role, separate from Power BI workspace admin. The people who should hold database credentials aren't usually the people building reports.

Check again if the client moves sources to Azure — a VNet gateway may take a server off their hands.

Was this accurate?
Related
Scheduled refresh03-power-query-and-dataflowsSemantic model fundamentals01-semantic-modelsDataflows03-power-query-and-dataflowsXMLA endpoint09-alm-and-deploymentFabric capacity and F SKUs06-capacity-and-performanceOneLake and workspace items05-service-and-workspaces