On-premises data gateway

What it does

The on-premises data gateway is a Windows client application installed on a machine inside the customer's network that acts as a bridge between on-premises data sources and Microsoft cloud services. It makes only outbound connections and polls for work, so no inbound ports need opening.

Key facts

One installation serves all supported services: Power Apps, Power Automate, Power BI, Azure Logic Apps, Azure Data Factory, Azure Analysis Services and Microsoft Fabric.
Two types. The standard on-premises data gateway supports multiple users and multiple data sources. Personal mode is single-user and works only with Power BI.
There's also a virtual network data gateway, a Microsoft-managed service with nothing to install, for sources secured behind a virtual network.
Power Apps, Power Automate and Logic Apps get both read and write through the gateway, with documented limits: 2 MB payload for writes, 2 MB request and 8 MB compressed response for reads, and 2,048 characters for a GET request URL.
Power BI DirectQuery has a separate 16 MB uncompressed response limit.
Each gateway cluster — enterprise or personal — supports a maximum of 1,000 data sources.
Credentials are cached client-side for performance and the cache expires in a matter of hours. Change a credential and the old one can keep being used for roughly five hours, which shows up as refreshes failing for no apparent reason.
Microsoft supports only the last six releases and ships an update every month. That's a six-month support window, not a "when we get round to it" one.
Gateway admins are managed in the Power Platform admin center for Power Platform, and in the Power BI service for Power BI.
Windows Authentication through the gateway is implicitly shared. The connector has access to everything those credentials can reach, and the connection is published with the app.

When to use / skip

You need a gateway when the data genuinely can't move — a line-of-business SQL Server, an on-premises SharePoint farm, a file share — and the business has accepted that a canvas app will be querying it live. If the data could reasonably be replicated into Dataverse or Azure SQL on a schedule, do that instead, because a gateway adds a single point of failure inside someone else's network that you will be blamed for and can't monitor properly. Where the gateway is unavoidable, treat it as production infrastructure from day one rather than as a thing someone installed on a spare VM.

Configuration decisions

Cluster membership and how many members. A single-node gateway is a single point of failure for every app and flow that uses it.
Which machine it runs on, sized for the query load rather than for the installer's minimum. It's a service, not a utility.
Who the gateway admins are, and whether that's the same team who patch the host — because the monthly update cadence and six-release support window need an owner.
Which authentication type each data source uses, given Windows Authentication means the connector runs with those credentials for every app user.
Whether the workload fits inside the 2 MB write and read request ceilings, which decides whether a bulk operation is even possible through this route.

Gotchas

The six-release support window means a gateway left alone for seven months is unsupported. Nobody notices until they open a ticket and are told to upgrade first.
The credential cache expiring "in a matter of hours" means a password change appears to work, then breaks, then fixes itself. That's a very hard ticket to triage without knowing about the cache.
The 2 MB write payload limit is small. Any pattern that pushes a batch of records or a file through the gateway hits it, and the error doesn't say "your payload is too big for the gateway" in as many words.
Gateway clusters are shared infrastructure. A Power BI dataset refresh saturating the host affects every canvas app on the same cluster, and neither team owns the other's workload.
The host machine going down takes every dependent app and flow with it, and the gateway is usually on the one VM that isn't in the standard patching and monitoring scope.

Consultant notes

Get the gateway into the infrastructure conversation early, with a named owner and a monitoring plan. Delivered as an afterthought it becomes the project's most reliable source of production incidents.
Insist on a cluster with at least two members for anything user-facing. The extra machine is cheap relative to one outage.
Set expectations about latency. Every query makes a round trip through a polling client on a machine inside the customer's network, and it will not feel like Dataverse.
Push back on gateways used to keep data on-premises for reasons nobody can articulate. Sometimes the answer is a real compliance requirement; often it's a preference that's costing the client an availability risk.

Worth revisiting if the gateway payload limits change, or when virtual network gateways become viable for more source types.