3.6 Querying: Visual Query, SQL, KQL, DAX
Key Takeaways
- Visual Query Editor is a low-code, graphical query builder (Power Query-based) for analysts who want results without writing code, over a lakehouse SQL endpoint or warehouse.
- T-SQL is used through the warehouse and the lakehouse SQL analytics endpoint (read-only on the lakehouse) for relational SELECT, joins, views, and stored procedures.
- KQL is the query language for eventhouse/KQL databases — built for streaming, telemetry, log, and time-series analysis (summarize, where, project).
- DAX queries and analyzes a semantic model (measures, filter context) — it is the consumption-layer language, not a data-preparation language.
- Pick the language by the asset: warehouse/lakehouse → SQL or Visual Query; eventhouse → KQL; semantic model → DAX.
One Question, Different Languages
The exam often shows the same business question against different assets and asks which query tool is appropriate. The decisive factor is what asset holds the data and who is querying it, not which language you personally prefer.
The Four Query Surfaces
- Visual Query Editor — a no-code/low-code graphical builder (Power Query under the hood) available over a lakehouse SQL analytics endpoint or a warehouse. Drag tables, apply filters/joins/aggregations visually; it generates the query for you. Best for analysts who want results without writing T-SQL.
- SQL (T-SQL) — used in the warehouse (full read-write) and the lakehouse SQL analytics endpoint (read-only). Use for relational
SELECT/JOIN/GROUP BY, views, and (warehouse only) stored procedures and DML. - KQL (Kusto Query Language) — the language of the eventhouse/KQL database. Operators like
where,summarize,project, and time-series functions make it ideal for telemetry, logs, and event analytics. - DAX — queries and computes over a semantic model: measures, filter/row context, time intelligence. It is the consumption language for BI, not a data-prep or raw-table language.
Choose-the-Language Table
| Asset / scenario | Use |
|---|---|
| Lakehouse tables, analyst, no code | Visual Query Editor |
| Lakehouse tables, read-only T-SQL | SQL analytics endpoint (T-SQL) |
| Warehouse, relational DML / procedures | T-SQL (warehouse) |
| Eventhouse, telemetry / time-series | KQL |
| Semantic model measure / report logic | DAX |
| Quick relational result, no SQL skills | Visual Query Editor |
SQL Analytics Endpoint: The Detail That Trips Candidates
Every lakehouse automatically provides a SQL analytics endpoint. You can run T-SQL SELECTs, create views, and connect BI tools to it — but it is read-only with respect to the lakehouse Delta tables. To change lakehouse data you go back to Spark/notebooks/Dataflow Gen2. If a query scenario needs T-SQL writes or stored procedures, that points to a warehouse, not the lakehouse endpoint. This is the single most common DP-600 query distractor.
KQL for the Eventhouse
When a scenario mentions device telemetry, logs, or "how many events per 5-minute bin," the answer surface is KQL in the eventhouse. KQL's summarize ... by bin(Timestamp, 5m) pattern is purpose-built for time-series and is far more natural than forcing the same logic into T-SQL or DAX.
DAX Is Not a Prep Language
A frequent trap offers DAX as an answer for transforming or cleaning raw tables. DAX is for semantic model calculation and analysis (measures, filter context, time intelligence) — it consumes a modeled star schema, it does not ingest, clean, or reshape source data. Keep preparation in lakehouse/warehouse engines and reserve DAX for the model layer.
A business analyst with no SQL coding skills needs to filter and aggregate tables in a Fabric lakehouse and get results quickly without writing T-SQL. Which query approach best fits?