If your data is stored on an internal server, then you need an On-Premises Gateway for data refresh on Power BI Service. In today’s post, we will discuss how to determine the correct sizing for your On-Premises Data Gateway machine.

Determining the correct sizing for your Gateway machine can depend on the following :

For Import mode:

• The type of the datasource
• The size of the data to import to Power BI
• Transformations required by the Power Query mashup engine
• The size of the data to publish to the Power BI service
• The number of concurrent dataset refreshes

Cache data workloads require enough CPU and Memory.

For Live Connection and DirectQuery:

• The number of concurrent report users
• The number of visuals on report pages
• The frequency of Power BI dashboard query cache updates
• The number of real-time reports using the Automatic page refresh feature
•  Row-level Security (RLS) dataset enforcement

Live Connection and DirectQuery workloads require sufficient CPU.

Power BI and the On-Premises Data Gateway create temporary cache files when communicating between the on-premises environment and the cloud in a process called spooling. Depending on how much disk space you have available for spooling, an “out of disk space” error can occur when disk space is full because of the spooler. To fix the “spooling out of disk space error “, check here.

Power BI capacities also impose limits on model refresh parallelism, Live Connection and DirectQuery throughput. There’s no point in sizing your Gateways to deliver more than what the Power BI service supports. For minimum requirements and consideration, check here.

To avoid a single point of failure, and to balance the load across multiple Gateways, use a Gateway cluster.

For additional information, check the Microsoft documentation here.

🙂 Happy administration