Azure Data Explorer (ADX) is a fast and highly scalable data exploration service for log and telemetry data. It’s an excellent tool for data analytics that offers multiple ways to interact with your data.
You can interact with Azure Data Explorer directly through several interfaces:
Each tool offers advantages depending on your workflow and preferences. For example, if I need to jump to the same tables, queries and functions in between performing other tasks, the desktop Kusto Explorer is easier to find again amidst all open applications and browser tabs. When jumping between a lot of different adx clusters and databases, I prefer having different browser tabs open for each database. In Kusto Explorer the current context may switch for several tabs at the same time.
As a beginner, you might not notice much difference between these tools. Personally, I started using Kusto Explorer because I was so used to hitting F5 to execute queries from other SQL applications that in the browser, I accidentally reloaded the page all the time. A couple of months later, muscle-memory kicked in, and Shift+Enter now works perfectly in all three tools.
However, there are actual differences in how Kusto Explorer parses queries, as you will see below.
While the user experience is similar, Kusto Explorer (the desktop app) and web-based tools can handle query parsing differently.
For example:
This means a query that works in one tool might not always behave the same way in another. It’s a good idea to test important queries in the interface where they’ll be used most.
A prominent case I encountered was the behavior when using raw (or literal) strings. Like in Markdown code blocks, in KQL you can wrap strings in three backticks:
```my string```This marks the string as “raw,” meaning it won’t be interpreted in any way. This is very handy when querying tables containing strings with queries. To query this information, you could do something like:
MyTable | where query_col has ```Foo | where col has 'bar'```This ensures that KQL doesn’t interpret the string as part of the query, avoiding the need to escape every special character individually.
Executing this via web browser works just fine. Doing the same in Kusto Explorer will yield an empty result—no error, just a result set of zero.
So, as always, test with sample data to verify that the actual result matches the expected outcome of your query! 😊
Another strange behavior I encountered recently is that Kusto Explorer (the desktop app) lost the ability to connect to specific individual databases. The only displayed error was that a connection could not be established.
Recreating the data connection worked for a couple of days and then disappeared again.
The solution came from the ADX developer team:
Disable the option: Tools → Options → Connections → Lite schema exploration protocol
Now I know there’s a “Lite schema exploration protocol” (whatever that might be), but that’s a story for another blog post!
No tool is perfect, and I still love using Kusto Explorer — albeit with a little more caution than before. The key takeaway is to always test your queries thoroughly and be aware that different interfaces might handle the same KQL differently.
Happy querying! 🚀
PS: Unfortunately, there are no plans yet to offer a MacOS or Linux port of Kusto Explorer
