Watch a smart, curious person try to learn SQL. They get through SELECT * FROM x WHERE y and they’re fine. Then they hit JOIN, or GROUP BY, or a correlated subquery, and the floor opens up. Most never come back.
KQL is the opposite. It reads left to right, the way the human brain wants to think about data.
PageViews
| where TimeGenerated > ago(7d)
| where ClientCountryOrRegion == "United States"
| summarize count() by bin(TimeGenerated, 1d), Page
| top 10 by count_Read it out loud. “Take page views, where time is in the last seven days, where the country is the US, summarize by day and page, give me the top ten.” That sentence is the query. Nothing is hidden, nothing is out of order.
The verbs are English. where. summarize. project. extend. take. top. There’s no CROSS APPLY lurking three chapters in.
You can do useful work on day one without ever learning a join. That matters more than engineers remember. Every join is a cliff for a non-engineer, and SQL puts that cliff in front of trivial questions. KQL puts the cliff somewhere on chapter five.
Add to that:
- Sane defaults —
take 100to peek, results are always tabular - Time-series operators baked in —
ago,bin,series_decompose - Autocomplete that actually understands your schema
- A query pane that gives you instant feedback the moment you stop typing
KQL isn’t the right tool for everything. I’d never reach for it to build a transactional system. But for letting smart, curious people answer their own questions about their own data, I haven’t seen anything better.
Take all that with a grain of salt — I wrote a KQL-to-SQL parser and generator, so I’m clearly not sure what any of this means.