Partitions are the key to scaling in-memory SSAS Tabular models as only certain partitions, such as the partitions representing the last two months of data, need to be included in a recurring refresh process.

These partitions can be defined in SQL Server Data Tools (SSDT) as shown in the following screenshot, and many patterns and practices have been documented for automating the management and refresh of partitions:

In the preceding screenshot, the Reseller Sales table is comprised of multiple yearly partitions (that is, ResellerSales2018). In most large models, the partitions would be much smaller (months, weeks) and logic would be built into a refresh process for dynamically determining which partitions to process and which (if any) to add or delete. Incremental data refresh for Power BI datasets hosted in Power BI Premium capacities is expected to offer the same essential as partitions in terms of minimizing refresh times and resources. However, it's unlikely that incremental data refresh will offer the same level of complete control.

Scaling out query workloads across multiple Analysis Services servers and implementing load balancing is also a very important feature of enterprise deployments. Azure Analysis Services greatly simplifies this setup and the planning involved by providing the following interface in the Azure portal:

As shown in the preceding screenshot, up to seven query replicas of an Azure Analysis Services server can be created. If the processing server responsible for the data refresh process is not separated from the querying pool, a total of eight analysis services servers would be available in the Azure cloud to resolve queries from Power BI and other tools such as Excel and Tableau with load balancing provided automatically by Azure Analysis Services.

Scale out architectures are certainly also supported with SSAS Tabular in on-premises environments, but require significantly more planning and coordination to provision and configure the infrastructure.