Forum Discussion

supton's avatar
supton
Helper I
9 years ago
Solved

Poor Performance using Azure SQL Database and Direct Query

Hello! I was just wondering if anyone else has experienced very poor performance using Direct Query on an Azure SQL Database. I have limited the number of rows that I am using in my queries but this ...
General Comment
Need Help
  • Anonymous's avatar
    Anonymous
    9 years ago

    supton,

    I am afraid that there is no way around this. Generally speaking, import models will be faster, and 500 thousand rows is not a large dataset, it is recommended that you use “Import” mode to import data to Power BI.

    Regards,
    Lydia

supton's avatar
supton
Helper I
9 years ago

I would want to agree, but I can run straight sql queries against the database and they run without a problem, much more quickly than power BI seems to handle them and with much less effort. The bottleneck here appears to be Power BI.

Anonymous's avatar
Anonymous
Not applicable
9 years ago

Did you capture the *actual* query that Power BI is sending to query?

 

ImkeF We need you :)

  • ImkeF's avatar
    ImkeF
    Community Champion
    9 years ago

     

    Sorry, I have no experience with direct query mode :-)

  • supton's avatar
    supton
    Helper I
    9 years ago

    Actually, I didn't. I merely queried the views that I am using directly. Thanks for pointing this out. But I see that Power BI adds a lot of extra statements when selecting the data. Is there a way around this, or to actually just send a direct SQL statement to the server and return the columns? 

    • Anonymous's avatar
      Anonymous
      Not applicable
      9 years ago

      supton,

      I am afraid that there is no way around this. Generally speaking, import models will be faster, and 500 thousand rows is not a large dataset, it is recommended that you use “Import” mode to import data to Power BI.

      Regards,
      Lydia

      • supton's avatar
        supton
        Helper I
        9 years ago

        I understand. This was the route which I took initially. But I was unable to schedule a refresh because of the largest table (which was 1.5 million before it was split). The refresh took too much time, and the scheduled refresh would crash because of this. It would take over an hour to process any refresh of the data on my local machine.