Elasticsearch 1.6: What's New, Release History & EOL Status

What Is New in Elasticsearch 1.6

Elasticsearch 1.6 delivers significant enhancements across core functionality, scripting, and cluster operations. This release focuses on improving stability, performance, and giving developers more powerful tools for data manipulation.

What scripting improvements make 1.6 stand out?

The headline feature is the introduction of the Painless scripting language. Painless is designed to be safe, fast, and simple, addressing performance and security concerns with inline Groovy scripts.

It's enabled by default for inline and stored scripts. In practice, this means your aggregations and document updates can run significantly faster without the overhead of the Groovy sandbox. Groovy scripting is now deprecated for inline and stored scripts, so migrating to Painless is recommended.

How did real-time GET operations get better?

Realtime GET requests now honor document versioning. Previously, a realtime GET could return a document that was in the process of being indexed, potentially showing an older version if a newer one had just been committed.

This change ensures strong consistency; you always get the latest versioned document even in a high-throughput environment. It removes a subtle edge case that could cause confusion in applications relying on immediate data visibility after an index operation.

What new control do we have over index refreshes?

The new Wait for Refresh API (_refresh?wait_for) allows you to block until a refresh has made indexed data available for search. This is different from the forced refresh API, which triggers the action immediately.

Use this when your application logic requires that a just-indexed document must be immediately searchable, such as in a test suite or a synchronous import process. It provides a way to synchronize indexing and searching without hammering the cluster with manual refresh calls.

Were there any notable aggregation enhancements?

Yes, the terms aggregation saw a major performance boost, especially for large datasets. The optimization reduces memory usage and improves query latency when bucketing on high-cardinality fields.

We also got the new bucket selector aggregation, which lets you filter out buckets from the results based on a script. This is powerful for post-aggregation logic, like only keeping buckets where the average value exceeds a certain threshold.

How was the snapshot/restore process improved?

The snapshot process is now more resilient. It better handles cases where a node drops out during the snapshot, allowing the operation to continue on the remaining nodes instead of failing completely.

Restore operations gained the ability to transform restored data on the fly. You can now apply index name patterns during a restore, making it much easier to clone data from a backup into a new index for testing or data recovery purposes.