Power BI DirectQuery
Parent: Atlas SQL Interface MongoSQL · Published reference · snapshot 2026-10-23 · viability 3.00 / 5 (skip)
↓ Facts as markdownall context files
Source-anchored research for Power BI DirectQuery. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
How it works
- Generated SQL depends on the DAX expression and model. SQLBI demonstrates that rewriting time-intelligence calculations can simplify SQL and reduce data exchange, so tuning only database indexes can miss a report-side cause. (high confidence) [source]
- Databricks’ 2025 Power BI guidance says too many visuals may produce queries queued by Power BI or Databricks, even when an individual query runs quickly; it recommends checking Power BI’s parallel query volume and the Databricks SQL warehouse’s capacity. This Databricks-specific guidance does not establish queueing behavior for the MongoDB SQL Interface connector. (medium confidence) [source]
Problems, failure modes and limitations
- Start with one slow visual in Power BI Desktop. Use Performance Analyzer to isolate report work, then inspect source-side diagnostics; investigate service or gateway differences when Desktop does not reproduce the problem. (high confidence) [source]
- DirectQuery Power Query transformations must fold. If a transformation cannot fold, move suitable logic into source views or prepared tables; database-side preparation can reduce work generated by the report. (medium confidence) [source]
Comparisons and alternatives
- Power BI DirectQuery evaluates report requests against the underlying data source rather than using the standard Import-mode copy; MongoDB exposes this through its SQL Interface connector. (high confidence) [source]
- DAX Studio can show generated SQL and formula-engine versus storage-engine duration for DirectQuery SQL models; its SQL Server CPU count of zero must not be interpreted as proof that the database consumed no CPU. SQLBI explains that Tabular treats this time as waiting. (low confidence) [source]
Facts and statements
- The MongoDB Atlas SQL connector supports Import and DirectQuery for Power BI semantic models and requires the MongoDB ODBC driver. (high confidence) (verified as of 2026-10-09) [source]
- For profiling, distinguish the report/DAX request from the generated source queries: one DAX request can produce multiple DirectQuery requests. SQL Server Profiler can inspect the Power BI session trace, while database-side diagnostics examine source execution. (high confidence) [source]
- Power BI Desktop FlightRecorderCurrent.trc can be opened in SQL Server Profiler. Query Begin/End describe DAX; DirectQuery Begin/End describe source requests. ActivityID groups interleaved events. This is semantic-model tracing, not proof of database-internal execution cost. (low confidence) [source]
- A short database execution time does not establish a fast DirectQuery visual. Client result fetching, large result sets, queueing and report processing can still dominate; inspect both source diagnostics and Power BI timings. (high confidence) [source]
- In a January 2026 SQL Server experiment, Chris Webb observed a DirectQuery result of 475,038 rows and roughly 1.1 seconds spent reading data; DataReadDuration exposed client consumption time that server query timing alone would miss. These are example measurements, not general DirectQuery benchmarks. (low confidence) [source]
- Microsoft documents native SQL visibility in Performance Analyzer for SQL Server, Oracle and Teradata, and documents a limited set of sources writing all DirectQuery queries to FlightRecorderCurrent.trc. MongoDB is absent from both lists; DirectQuery connector support alone therefore does not establish equivalent SQL trace visibility. (medium confidence) (verified as of 2026-10-09) [source]
- For Power BI on Databricks, combine Performance Analyzer with Query History and Query Profile. Databricks recommends examining queueing, execution, client fetching and rows returned; this is a concrete example of pairing report-level and database-level profiling. (low confidence) [source]
- MongoDB documentation lists DirectQuery support with Power BI Connector and ODBC driver version 1.2 or later, and warns that unsupported actions can prompt switching to Import Mode. (low confidence) (verified as of 2026-10-14) [source]
- DAX Studio Server Timings exposes DirectQuery storage-engine requests and separates formula-engine and storage-engine duration. This helps identify expensive generated requests and compare DAX rewrites before investigating the database. (high confidence) [source]
- For Power BI on Databricks, pair Performance Analyzer with SQL warehouse Query History and Query Profile. Query History distinguishes scheduling, optimization, execution, and client result fetching; Query Profile exposes expensive tasks and resource use. (low confidence) [source]
- DAX Studio documents that DirectQuery trace text can be generic T-SQL transformed before source execution. Therefore, validate the executed statement using source-side capture before replaying trace text against another database. (low confidence) [source]
Children
- No children recorded.