Testing The Latest Features of ES|QL in Elasticsearch 9.5

Introduction

ES|QL is Elasticsearch's piped query language, one readable statement instead of extensive Query DSL. It has become the default way to filter, aggregate, and correlate data across modern Elastic deployments, and every release pushes it further toward one goal: making all your data actually queryable, not just stored.

Elastic brings five new capabilities in ES|QL in Elasticsearch 9.4, all now Generally Available (GA): Subqueries, Approximate Queries, Logical Views, JSON Function Extraction, and Access to All Ingested Fields. Rather than testing each sequentially, we set up a small multi-source log environment on Elasticsearch 9.5 and worked through a realistic scenario: correlating events across three genuinely different log sources during incident triage.

The Setup

We ingested three public log datasets (via Logstash, into Elastic Cloud) that each have a different schema by nature. We chose:

• HDFS: distributed storage logs (Component, Pid, Level)
• Apache: web server logs (Level, Content but no Component or Pid at all)
• OpenSSH: auth logs (Component, Pid, plus real security-relevant content like failed logins and break-in attempts)

Each pipeline also packed a couple of fields into a stringified JSON field (raw_metadata) on ingest, giving us something real to test JSON_EXTRACT against.

1. Subqueries: One Timeline, Three Schemas

The first question was simple: can I see events from all three services in one sorted timeline, without three separate searches?

Each inner query runs its own independent pipeline before merging. Apache has no Component field, so those rows simply return null for it in the merged output; real schema mismatch, handled without any manual cleanup.

Adding a severity breakdown on top was a one-line change.

One query, three sources, an immediate answer to "which service is noisiest and at what severity."

2. Logical Views: Save It, Reuse It

Once the subquery was concrete, we wrapped it as a named view instead of re-pasting it every time:

From here on, every dashboard or alert just does FROM incident-triage - the three-way merge logic lives in one place, defined once.

3. JSON Function Extraction

Each source's raw_metadata field is a stringified JSON blob.

HDFS and OpenSSH contain the fields component, event_id, and pid, whereas Apache only has event_id, since that's all the source data gives it.

No reindexing, no pipeline changes, just pull the fields out at query time. And it composes cleanly with subqueries each inner query can extract its own fields before the merge happens, so the combined output still lines up even though the underlying JSON shapes differ per source.

4. Access to All Ingested Fields

To test this one properly, I built a second data stream with the setting "dynamic": false in its mapping, deliberately excluding the EventTemplate field from the mapping while it still landed in every document's _source field.

Without the fix,

that field is effectively invisible to a query. But with the setting:

One SET line, and a field that was missed at mapping time becomes queryable again no reindex window required.

5. Approximate Queries

Same query, one line added:

On a small dataset the difference is mainly negligible; the real payoff (sampled results with confidence signals, dramatically faster on large volumes) only becomes visible at real production scale. Worth testing if you've got billions of documents to aggregate over, but the syntax and behavior are already there to try.

Takeaways

What stood out wasn't any single feature, it was how naturally they combined that was the real finding here. A subquery merges mismatched sources, a logical view makes that merge reusable, JSON extraction and unmapped-field access reach into data the mapping never anticipated, and approximate queries make the whole thing viable at scale. Put together, they cut a multi-step manual investigation down to a query you save once and reuse.

All five were introduced as Technical Preview in 9.4, but as of recent versions, they are Generally Available and worth testing now, with guaranteed performance in production environments. The direction is clear: ES|QL is closing the gap between "the data exists" and "the data is actually reachable."