My team comes from Azure Data Explorer / Microsoft Sentinel / Log Analytics, where
KQL (Kusto Query Language) is the native query language. Our analysts and SREs think
in KQL's pipe-based flow (source | where ... | summarize ... | project ...), and we
have a large library of saved queries, detections, and dashboards written in it.
Quickwit today exposes its own Lucene-style query mini-language and an
Elasticsearch-compatible DSL. Both are great for full-text filtering, but neither
maps cleanly onto the multi-stage transform-and-aggregate workflow KQL makes natural.
Porting existing KQL assets to Quickwit means rewriting everything by hand, which is a
major blocker to adopting Quickwit as a log/trace backend for teams already fluent in KQL.
Describe the solution you'd like
First-class KQL support, exposed as an additional query language (e.g. a
query_language=kql parameter on the existing search endpoints, or a dedicated
/kql endpoint) that parses KQL and translates it into Quickwit's internal
query + aggregation execution.
A useful initial subset, in rough priority order:
- Filtering:
where, search, time-range predicates
- Shaping:
project, project-away, extend, rename
- Aggregation:
summarize with count(), sum(), avg(), min()/max(),
dcount(), and bin() for time bucketing — these map onto Quickwit's existing
metric/bucket aggregations
- Ordering & limiting:
sort/order by, take/limit, top
- String/scalar functions and
case/iff as a later phase
Out-of-scope clauses (join, mv-expand, user-defined functions, etc.) could return
a clear "unsupported operator" error rather than silently misbehaving.
Example translations (KQL on the left, the Quickwit operation it would lower to on the right):
- Errors bucketed over time
My team comes from Azure Data Explorer / Microsoft Sentinel / Log Analytics, where
KQL (Kusto Query Language) is the native query language. Our analysts and SREs think
in KQL's pipe-based flow (
source | where ... | summarize ... | project ...), and wehave a large library of saved queries, detections, and dashboards written in it.
Quickwit today exposes its own Lucene-style query mini-language and an
Elasticsearch-compatible DSL. Both are great for full-text filtering, but neither
maps cleanly onto the multi-stage transform-and-aggregate workflow KQL makes natural.
Porting existing KQL assets to Quickwit means rewriting everything by hand, which is a
major blocker to adopting Quickwit as a log/trace backend for teams already fluent in KQL.
Describe the solution you'd like
First-class KQL support, exposed as an additional query language (e.g. a
query_language=kqlparameter on the existing search endpoints, or a dedicated/kqlendpoint) that parses KQL and translates it into Quickwit's internalquery + aggregation execution.
A useful initial subset, in rough priority order:
where,search, time-range predicatesproject,project-away,extend,renamesummarizewithcount(),sum(),avg(),min()/max(),dcount(), andbin()for time bucketing — these map onto Quickwit's existingmetric/bucket aggregations
sort/order by,take/limit,topcase/iffas a later phaseOut-of-scope clauses (
join,mv-expand, user-defined functions, etc.) could returna clear "unsupported operator" error rather than silently misbehaving.
Example translations (KQL on the left, the Quickwit operation it would lower to on the right):