Learn from the best! Meet the four finalists headed to the FINALS of the Power BI Dataviz World Championships! Register now
I connected my Excel and Power B through Power Query to SQL Server Database to get data for analysis. I am able to do all analysis I do in SQL in Excel and Power BI Power Query. Should I continue like this or which route is better: Excel & Power BI Power Query or Sql. Thanks.
Solved! Go to Solution.
Hi @OlaOlu ,
If I understand your question correctly, you're asking whether to perform data transformations using SQL, or Power Query what the ideal approach, and visualizing the data in Excel (after building the semantic model) or Power BI.
If you're able to perform the same Power Query operations in SQL, it's best to push the transformations as close to the source as possible. This approach reduces the load on the Power BI layer because the source is designed to handle these transformations effectively.
Excel analysis is typically used for ad hoc reporting by business users who are familiar with Excel functions. Power BI reports offer advantages in terms of sharing and usability.
Prepare your query in sql (else use the PQ) -> load the data in pbi -> start with basic modellling -> adhoc analysis -> visuals -> bring in the standards -> share the reports
Thanks
If this response was helpful in any way, I’d gladly accept a kudo.
Please mark it as the correct solution. It helps other community members find their way faster
Hi @OlaOlu
As a best practice, good to use SQL for most of the data transformations and Power Query for minimal data cleaning.
Use SQL for heavy transformations (joins, aggregations, large datasets), it’s faster, scalable, and easier to maintain centrally. Use Power Query for light shaping, combining sources, and preparing data close to the report. If you’re doing complex logic repeatedly in Power Query, that’s usually a sign it should move to SQL. A common best practice is: SQL handles the data prep, Power Query handles the final shaping. This gives you better performance, governance, and reusability across reports.
Use SQL for heavy transformations (joins, aggregations, large datasets), it’s faster, scalable, and easier to maintain centrally. Use Power Query for light shaping, combining sources, and preparing data close to the report. If you’re doing complex logic repeatedly in Power Query, that’s usually a sign it should move to SQL. A common best practice is: SQL handles the data prep, Power Query handles the final shaping. This gives you better performance, governance, and reusability across reports.
Hi @OlaOlu
As a best practice, good to use SQL for most of the data transformations and Power Query for minimal data cleaning.
Hi @OlaOlu ,
If I understand your question correctly, you're asking whether to perform data transformations using SQL, or Power Query what the ideal approach, and visualizing the data in Excel (after building the semantic model) or Power BI.
If you're able to perform the same Power Query operations in SQL, it's best to push the transformations as close to the source as possible. This approach reduces the load on the Power BI layer because the source is designed to handle these transformations effectively.
Excel analysis is typically used for ad hoc reporting by business users who are familiar with Excel functions. Power BI reports offer advantages in terms of sharing and usability.
Prepare your query in sql (else use the PQ) -> load the data in pbi -> start with basic modellling -> adhoc analysis -> visuals -> bring in the standards -> share the reports
Thanks
If this response was helpful in any way, I’d gladly accept a kudo.
Please mark it as the correct solution. It helps other community members find their way faster
A new Power BI DataViz World Championship is coming this June! Don't miss out on submitting your entry.
Share feedback directly with Fabric product managers, participate in targeted research studies and influence the Fabric roadmap.
| User | Count |
|---|---|
| 47 | |
| 36 | |
| 27 | |
| 15 | |
| 15 |
| User | Count |
|---|---|
| 58 | |
| 56 | |
| 38 | |
| 21 | |
| 21 |