What's New in Elasticsearch 7.10

If your cluster is running an older Elasticsearch 7.x release, such as 7.2, we may upgrade it to Elasticsearch 7.10.2. This page explains what that means for you and what you gain in the process.

The short version: this is a minor version upgrade within the 7.x series. Your data, indices, credentials, and cluster URL stay exactly the same, and your application does not need to change. You get several years of stability, performance, and security improvements for free.

Why We're Upgrading

Bonsai supports a limited set of Elasticsearch versions on multitenant clusters so that we can provide reliable operational support and timely security response across the fleet. 7.10.2 is the current standard for the 7.x series. Consolidating older 7.x clusters onto 7.10.2 lets us keep every 7.x cluster on a version that receives our full operational attention. See How Bonsai Handles Elasticsearch Releases for the full policy.

What You Gain

Every release between 7.2 and 7.10 layered on improvements. Here are the changes most likely to matter for a typical Bonsai workload.

Stability and Security

You move from a 2019-era release onto one that received nearly two more years of bug fixes and security patches. This is the single biggest reason to be on 7.10.2: fewer known issues, and a version we can support and patch effectively.

Performance and Efficiency

• Lower memory footprint. A series of heap-usage reductions across 7.3–7.10 means the same cluster handles more mappings and more concurrent work before hitting memory pressure. This is especially noticeable on clusters with large or numerous indices.
• Faster indexing. Indexing throughput improved measurably over the 7.x series for many workloads.
• Smaller indices. 7.10 improved compression of stored fields, reducing on-disk index size for many workloads with no configuration changes. Smaller indices mean more headroom under your plan's storage limit.
• Faster aggregations. Date histogram aggregations — a common building block for dashboards and analytics — were significantly optimized.

Search Capabilities

These are opt-in features. You don't have to use them, but they're available on 7.10.2 if you want them:

• search_as_you_type field type (added in 7.4) — a purpose-built field for autocomplete and instant-search experiences, without hand-rolling edge-ngram mappings.
• Pinned queries (7.4) — promote specific documents to the top of results, useful for merchandising, curated results, and sponsored placements.
• Vector search foundations — dense_vector fields with script_score let you build semantic and similarity search using embeddings, the basis for modern AI-powered search.
• Async search (GA in 7.7) — run long or heavy queries in the background and collect results as they complete, instead of holding a request open.
• Point-in-time reads (7.10) — a lightweight way to run consistent, paginated queries against a fixed view of your data.

New Field Types and Data Handling

• version field type (7.10) — sorts and compares software version strings using semantic-versioning rules rather than plain string ordering.
• unsigned_long (7.10) — support for unsigned 64-bit integers, up to 2⁶⁴-1, for large counters and system-generated identifiers.
• Composable index templates (GA in 7.8) — build index templates from reusable component templates, which makes managing mappings and settings across many indices far less repetitive.

Will Anything Break?

No breaking changes were introduced within the 7.x line, so an upgrade from 7.2 to 7.10.2 should be transparent to your application. Features that were deprecated during 7.x still function in 7.10.2 — they don't get removed until Elasticsearch 8. If your use case depends on something niche, the safest check is to test your queries against the new version before the change. When in doubt, reach out to support.

I Need to Stay on My Exact Version

Some use cases are pinned to an exact engine version — for example, compatibility testing, regulatory requirements, or a client library locked to a specific release. On multitenant plans, Bonsai can't pin a cluster to a version, because changing versions means migrating between shared server groups.

If you need control over when your engine version changes, upgrade to a Business cluster. Business and Enterprise clusters run on dedicated, single-tenant infrastructure, so version changes happen only when you request them. See How Bonsai Handles Elasticsearch Releases for details.

Questions?

We're happy to help. Email us at support@bonsai.io and we'll walk through what the upgrade means for your specific cluster.