ES|QL

What ES|QL changes in Elasticsearch

ES|QL is not just another search syntax, it is a pipeline language that lets you filter, transform, aggregate and reshape results as part of the query flow. That makes it especially useful when analysts want to move from raw indexed data to a more usable result set without exporting it first.

Because the query can do more work in one statement, ES|QL can reduce the number of separate searches or post-processing steps a team needs to stitch together. The trade-off is that poorly constructed queries can become harder to reason about, especially when several pipeline stages depend on earlier output fields.

How ES|QL processing works

ES|QL combines search and transformation into a left-to-right pipeline. Each stage can narrow the data, derive new fields, or summarise records, so the syntax reads more like a sequence of operations than a traditional query with nested clauses.

This matters because the query result is shaped during execution rather than after the fact. In practice, that gives users a compact way to express investigative questions, operational reporting, and ad hoc analysis over indexed data.

For teams already using Elastic Security, the language becomes even more valuable when it is applied to detections and investigation workflows. NHIMG’s Elastic Security Guide covers ES|QL alongside detection rules, API keys, service tokens and related operational controls.

Where ES|QL is strongest

ES|QL is strongest when the question is exploratory and the analyst needs both retrieval and reshaping in one pass. It is well suited to looking for patterns, grouping events, calculating summaries and preparing outputs that are easier to inspect or feed into another workflow.

That makes it useful for security operations, observability and data exploration where the value is not only in finding records, but in immediately structuring them into something meaningful. The language is therefore best understood as an analysis layer on top of Elasticsearch rather than a replacement for the underlying index model.

Its main limitation is that it depends on the quality and structure of the indexed data. If field naming, mapping consistency or source normalization is weak, ES|QL can still query the data, but the results will be less reliable and less efficient to work with.

ES|QL in operational analysis

In day-to-day use, ES|QL helps analysts reduce friction between “searching for data” and “making sense of it.” Instead of exporting records into another tool for grouping or transformation, users can often keep the whole workflow inside Elasticsearch.

This is especially helpful when teams need repeatable investigations, dashboard inputs or quick one-off analysis during an incident. The language encourages a more composable style of querying, where each step in the pipeline reflects a distinct analytical decision.

Because ES|QL can be used by both technical and security-oriented teams, clear query conventions matter. Shared patterns for naming, field selection and pipeline structure make queries easier to review, reuse and trust.

Related resources from NHI Mgmt Group

• How should teams replace __dirname and __filename when migrating Node.js code from CommonJS to ES modules?
• When should organisations prioritise URL-based file handling over path strings in ES modules?
• What do teams get wrong about using __dirname in ES module code?
• How does SEV-ES work?