Elastic 9.3: pattern_text, Streams and Workflows for logs

Elastic 9.3 became generally available on 3 February 2026. The announcement gives most of its space to AI agents and vector search, but an administrator who looks after logs will find several changes that matter more for day-to-day work. Below we describe the ones we think are worth testing on your own data, and we mark which are ready for production and which are still technical previews.

What 9.3 offers for logs and observability

Feature	Status in 9.3	Who it is for
pattern_text field	GA (preview in 9.2)	Teams with a large volume of text logs
Streams: agentic parsing of the message field	Technical preview	Administrators with unstructured logs
Elastic Workflows	Technical preview	Teams automating responses to alerts
Elastic Agent Builder	GA	Teams building their own AI agents on data in Elasticsearch
Metrics in ES|QL (time series commands, exponential histograms)	Technical preview	Teams with metrics in Elasticsearch

The statuses come from the Elastic 9.3 announcement and the field documentation. When you plan a rollout, go back to the documentation for each feature, because previews change between releases.

pattern_text: less space for repetitive messages

Much of an application log consists of the same sentences in which only the values change: a user ID, an address, a duration. The pattern_text field is a variant of text that splits such a value into a template (the repeating part) and variables. The template is not directly accessible, but the <name>.template_id field holds its hash, so you can group similar messages by it. Elastic says the field can cut storage by up to half. That is a vendor figure and it depends on the data.

The documentation also lists limitations you should know before changing a mapping:

• a document cannot hold several values in this field, because indexing returns an error,
• span queries are not supported, so you use interval queries instead,
• like text, the field is not used for sorting and has limited aggregations,
• phrase queries return a constant score of 1.0, so there is no relevance ranking,
• the feature requires a subscription.

For logs this is usually an acceptable price, because you are looking for events rather than the best-matching documents. For indices where relevance matters, stay with text.

How to test it on your own data

The most reliable test is to compare the same documents in two indices. Create a test index with a pattern_text field and sorting on the template ID (the documentation says compression improves noticeably when the index is sorted by template_id):

PUT logs-test-pattern
{
  "settings": {
    "index": {
      "sort.field": [ "message.template_id", "@timestamp" ],
      "sort.order": [ "asc", "desc" ]
    }
  },
  "mappings": {
    "properties": {
      "@timestamp": { "type": "date" },
      "message": { "type": "pattern_text" }
    }
  }
}

Then copy a sample of production logs from a few days into it and compare the size with an index in which message is an ordinary text field:

POST _reindex
{
  "source": { "index": "logs-production-sample" },
  "dest": { "index": "logs-test-pattern" }
}

GET _cat/indices/logs-*?v&h=index,docs.count,pri.store.size

Compare both indices once segment merging has finished and with the same number of documents. Also check that the queries used by your dashboards and alert rules still work. If you rely on quoted phrases or span queries, you will see the difference straight away.

The documentation also describes the index.logsdb.default_sort_on_message_template setting, which sorts by the message template for a pattern_text field named message. For indices in LogsDB mode, check it before you configure sorting by hand.

Questions to answer before the test

Before you change a mapping, answer three questions. Which log sources take up the most space? Are the messages in those sources repetitive (application and network device logs) or mostly unique (error dumps with entire stack traces)? Does anyone on the team use phrase or span queries in dashboards and rules? The pattern_text field gives the most where messages repeat and nobody depends on relevance ranking. If most of the space goes on long unique entries, the saving will be smaller than in the vendor’s examples.

Streams and parsing the message field

Streams is a set of Elastic features for working with logs, introduced in version 9.2. In 9.3 it gained an agentic process that analyses the message field and proposes how to split it into fields. This is a technical preview, so treat it as help with a first analysis, not as a replacement for a well-designed ingest pipeline. Check the proposed parsing on a sample before you save it for the whole stream. Organising log storage and parsing across a whole organisation is a separate topic, which we handle during deployments.

Workflows: automation in preview

Elastic Workflows is automation built into Kibana, based on rules, with manual, scheduled and alert triggers. In 9.3 the feature is a preview and is switched off by default. The documentation says you enable it in Kibana advanced settings with the workflows:ui:enabled option, and access is controlled by the Workflows privilege under Analytics. On production environments it is not worth building incident response processes on a preview.

What to watch when upgrading to 9.3

The list of breaking changes for 9.3 is short. Elastic describes, among other things, native synthetic _source for normalised keyword fields and cross-cluster functionality being disabled for _fleet/_fleet_search and _fleet/_fleet_msearch. If you use Fleet across several clusters, check this before upgrading. If you are upgrading from 8.x, start by reviewing your indices and settings, because 9.x requires a few preparation steps.

A few practical rules we follow with customers:

1. Test new field types on a copy of a data sample, not on a production index.
2. Enable technical previews only in a test environment and note which of them your team actually uses.
3. Before an upgrade, read the breaking changes for every release between your current and target version.

What this means for your cluster

If log storage is currently the biggest item in your cluster bill, pattern_text is the easiest candidate to test in 9.3. If your problem is parsing unstructured logs, try Streams on a copy of the data. For now, test automation in Workflows only outside production, for as long as the feature remains a preview.

We handle the choice of mappings, upgrades and storage cost analysis as part of Elastic deployments.