So, if DirectQuery is so great, why not choose it every time? Well, with every great feature you will also find limitations. The first glaring limitation is that not all data sources support DirectQuery. As of the time this book was written, the following data sources support DirectQuery in Power BI:
- Amazon Redshift
- Azure HDInsight Spark
- Azure SQL Database
- Azure SQL Data Warehouse
- Google BigQuery
- IBM Netezza
- Impala (Version 2.x)
- Oracle Database (Version 12 and above)
- SAP Business Warehouse Application Server
- SAP Business Warehouse Message Server
- SAP HANA
- Snowflake
- Spark (Version 0.9 and above)
- SQL Server
- Teradata Database
- Vertica
Depending on the data source you choose, there is a chance of slower query performance when using DirectQuery compared to the default data import option. Keep in mind that when the import option is selected it leverages a highly sophisticated in-memory storage engine. When selecting DirectQuery, performance will depend on the source type you have chosen from the list above.
Another limitation worth noting is that not all Power BI features are supported when you choose DirectQuery. For example, depending on the selected source, some the Power Query Editor features are disabled and could result in the following message: This step results in a query that is not supported in DirectQuery mode. Another example is that some DAX functions are unavailable when using DirectQuery. For instance, several Time Intelligence functions such as TotalYTD would generate the following type error when using DirectQuery:
The reason for this limitation is because DirectQuery automatically attempts to convert DAX functions such as this one to a query in the data source's native language. So, if the source of this solution was SQL Server, then Power BI would attempt to convert this DAX function into a comparable T-SQL script. Once Power BI realizes the DAX function used is not compatible with the source, the error is generated.