---
title: "Risky Operations in Elasticsearch and OpenSearch"
author: "Max Irwin"
date: 2025-10-01
canonical_url: https://bonsai.io/blog/risky-operations-in-elasticsearch-and-opensearch/
license: CC BY-SA 4.0
license_url: https://creativecommons.org/licenses/by-sa/4.0/
copyright: Bonsai.io, 2026
---

At Bonsai, we run search clusters for thousands of customers, and some of them have billions of documents. These clusters require dozens of large instances totaling thousands of CPUs, petabytes of Disk, and terabytes of RAM.

At this scale, lots can go wrong. We’re here to make sure everything runs smoothly so our customers can focus on delivering business value to their customers, and not worry about the intricacies of keeping such a large cluster healthy.

We’re also keen on making sure our customers can be flexible in what they do. We don’t lock everything down, but we’ve found that most people don’t know about the dangerous side of running certain operations. Some things can get particularly unsavory when run against a gigantic cluster that ingests millions of documents per day, and executes even more queries.

So, dear reader, welcome to the scary side of search. In this post we outline several features that exist in Elasticsearch and OpenSearch that can outright ruin your week if you’re not careful.

While it doesn’t cover absolutely everything, this is a good start to learning more about the many potential footguns in your engine. We’ve broken them up into some groups: Dangerous, Destructive, Spatial, Heavy Read/Write, and Config. Enjoy!

## Dangerous

These operations are called out first, in that they are non-obvious one-liners that will make things bad for everyone if you call them without realizing what the implications are. You should probably never use these unless you have a very specific reason and only with careful understanding and planning.

| Name/Operation | Description & Risks | Docs |
| --- | --- | --- |
| **Force Merge**  
`POST [/{index}]/_forcemerge` | Force segment merges to reduce segment count (optionally expunge deletes).
Heavy CPU/IO; can create very large segments and can run for DAYS.

 | [Elasticsearch: Force a merge](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-indices-forcemerge)  
[OpenSearch: Force Merge API](https://docs.opensearch.org/latest/api-reference/index-apis/force-merge/) |
| **Clear Cache**  
`POST [/{index}]/_cache/clear` | Clear request/query/fielddata caches for one or more indices.

Drops hot caches. Immediate latency/CPU spikes as caches rebuild.

 | [Elasticsearch: Clear Cache](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-indices-clear-cache)  
[OpenSearch: Clear Cache](https://docs.opensearch.org/latest/api-reference/index-apis/clear-index-cache/) |
| **Refresh**  
`POST [/{index}]/_refresh` | Explicitly refresh one or more indices to make recent writes searchable.

Synchronous and resource-intensive; rely on the periodic `index.refresh_interval` instead.

 | [Elasticsearch: Refresh API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-indices-refresh)  
[OpenSearch: Refresh Index API](https://docs.opensearch.org/latest/api-reference/index-apis/refresh/) |
| **Flush**  
`POST [/{index}]/_flush` | Force Lucene commit; fsync segments; rotate translog.

Burst I/O + segment churn if run broadly/frequently. It's usually unnecessary, and Lucene will do this for you.

 | [Elasticsearch: Flush API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-indices-flush)  
[OpenSearch: Flush API](https://docs.opensearch.org/latest/api-reference/index-apis/flush/) |

## Destructive

This section outlines ways to say goodbye to data. Obviously, you can delete an entire index in a single curl command, and that is typically run in very purposeful scenarios. But others are more devious. For example, you can delete by query - but triple check the query without the delete first and don’t YOLO your way into a week-long recovery effort!

| Name/Operation | Description & Risks | Docs |
| --- | --- | --- |
| **Delete Index**  
`DELETE /{index}` | Delete an index (irreversible unless you have snapshots).
Destructive; can break aliases and dependent apps; requires careful RBAC.

 | [Elasticsearch: Delete Index](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-indices-delete)  
[OpenSearch: Delete Index](https://docs.opensearch.org/latest/api-reference/index-apis/delete-index/) |
| **Delete By Query**  
`POST /_delete_by_query` | Delete all docs matching a query.

Full/large scan; can delete massive volumes; heavy merges; difficult to roll back.

 | [Elasticsearch: Delete By Query](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-delete-by-query)  
[OpenSearch: Delete By Query](https://docs.opensearch.org/latest/api-reference/document-apis/delete-by-query/) |
| **Close Index**  
`POST /{index}/_close` | Close index (no read/write/search; frees some resources).

Operational risk: apps fail on closed index; Ingestion will fail.

 | [Elasticsearch: Close Index](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-indices-close)  
[OpenSearch: Close Index](https://docs.opensearch.org/latest/api-reference/index-apis/close-index/) |

## Heavy Read/Write/Compute

When you’re serving lots of queries in a live environment, and decide you want to run some ad-hoc reports, get some comprehensive stats, take a snapshot, or reindex, you can slow things down for your customer application. Likewise, if you’ve got a new large dataset that exceeds your typical daily ingest that you want to toss into the index, you should have careful planning before doing so.

| Name/Operation | Description & Risks | Docs |
| --- | --- | --- |
| **Reindex**  
`POST /_reindex` | Copy documents from one index/alias/data stream to another (optionally filtered/transformed).
Very heavy read+write workload; can saturate I/O, heap, and network; can create version conflicts; best throttled or run off-peak.

 | [Elasticsearch: Reindex API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-reindex)  
[OpenSearch: Reindex API](https://docs.opensearch.org/latest/api-reference/document-apis/reindex/) |
| **Update By Query**  
`POST /{index}/_update_by_query` | Scan + script-update matching docs in-place.

Expensive full/large scan; scripts execute per-hit; version conflicts; large translog and segment churn.

 | [Elasticsearch: Update By Query](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-update-by-query)  
[OpenSearch: Update By Query](https://docs.opensearch.org/latest/api-reference/document-apis/update-by-query/) |
| **Create a Snapshot**  
`POST /_snapshot/{repository}/{snapshot}` | Filesystem/object-store snapshot of indices/cluster state.

Heavy I/O and repository load; long-running; can contend with indexing.

 | [Elasticsearch: Create Snapshot](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-snapshot-create)  
[OpenSearch: Create Snapshot](https://docs.opensearch.org/latest/api-reference/snapshots/create-snapshot/) |
| **Restore a Snapshot**  
`/_snapshot/.../_restore` | Restore indices/cluster metadata from snapshot.

Cluster-wide writes and shard allocations; can overwhelm nodes and disrupt routing.

 | [Elasticsearch: Restore Snapshot](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-snapshot-restore)  
[OpenSearch: Restore Snapshot](https://docs.opensearch.org/latest/api-reference/snapshots/restore-snapshot/) |
| **Disk Usage API**  
`/{index}/_disk_usage?run_expensive_tasks=true` | Analyze per-field on-disk footprint.

Expensive offline analysis; can be very resource intensive on large indices.

 | [Elasticsearch: Analyze Index Disk Usage](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-indices-disk-usage)  
OpenSearch: No Equivalent |
| **Scroll Search**  
`/_search?scroll=...` | Long-lived search contexts to page large result sets.

Holds resources per context; forgetting to clear can leak heap & file handles.

 | [Elasticsearch: Scroll API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-scroll)  
[OpenSearch: Scroll API](https://docs.opensearch.org/latest/api-reference/search-apis/scroll/) |

## Spatial (Disk & RAM consumption)

Have you ever run out of disk or memory? Talk about fun, if you’re bored these are just a really great way to find lots of work to do for the next 24 hours. Some operations unwittingly produce lots more data than you realize, sometimes double or more of your index. If you don’t have enough room, you’ll find out when the machines start complaining.

| Name/Operation | Description & Risks | Docs |
| --- | --- | --- |
| **Reindex**  
`/_reindex` | Copy documents from one index/alias/data stream to another (optionally filtered/transformed).
Very heavy read+write workload; can saturate I/O, heap, and network; can create version conflicts; best throttled or run off-peak.

 | [Elasticsearch: Reindex API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-reindex)  
[OpenSearch: Reindex API](https://docs.opensearch.org/latest/api-reference/document-apis/reindex/) |
| **Shrink Index**  
`/_shrink` | Rewrites an index into fewer primary shards.

Requires read-only state; creates new index; heavy reindex-like copy and segment rewrite.

 | [Elasticsearch: Shrink Index](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-indices-shrink)  
[OpenSearch: Shrink Index](https://docs.opensearch.org/latest/api-reference/index-apis/shrink-index/) |
| **Split Index**  
`/_split` | Rewrites an index into more primary shards (multiples only).

Requires read-only source; full rewrite; heavy disk/CPU.

 | [Elasticsearch: Split Index](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-indices-split)  
[OpenSearch: Split Index](https://docs.opensearch.org/latest/api-reference/index-apis/split/) |
| **Clone Index**  
`/_clone` | Clone an index to a new one (same shard count).

Faster than reindex, but still creates a full copy and transient resource spikes.

 | [Elasticsearch: Clone Index](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-indices-clone)  
[OpenSearch: Clone Index](https://docs.opensearch.org/latest/api-reference/index-apis/clone/) |
| **Point In Time**  
`/_pit` | Consistent snapshot for paginating searches.

Keeps segments pinned; too many/long `keep_alive` PITs consume disk/heap.

 | [Elasticsearch: Point-in-Time API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-open-point-in-time)  
[OpenSearch: Point-in-Time API](https://docs.opensearch.org/latest/api-reference/search-apis/point-in-time-api/) |
| **Restore a Snapshot**  
`/_snapshot/.../_restore` | Restore indices/cluster metadata from snapshot.

Requires you to close, delete, or rename the index. The former two may result in data loss, the latter requires enough space.

 | [Elasticsearch: Restore Snapshot](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-snapshot-restore)  
[OpenSearch: Restore Snapshot](https://docs.opensearch.org/latest/api-reference/snapshots/restore-snapshot/) |

## Mappings, Settings, and Aggregations

This section doesn't cover explicit operations, but rather things that you can add to mappings and settings that might result in things you don't want.

First things first: Don't use dynamic mappings. This means that you have data in a document that doesn't have a corresponding mapping property/field. This will result in that data being poorly optimized - so always ensure you are explicitly declaring your data in mappings with full coverage.

| Name/Operation | Description & Risks | Docs |
| --- | --- | --- |
| **Add a document without Mappings**  
`POST /{index}/_doc/{id}` | Automatic dynamic mapping updates.
Field explosion & poor types from dynamic mapping; mapping growth increases heap and slows queries.

 | [Elasticsearch: Dynamic mappings](https://www.elastic.co/docs/manage-data/data-store/mapping/dynamic-mapping)  
[OpenSearch: Dynamic mappings](https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/dynamic) |
| **Update Mappings**  
`PUT /{index}/_mapping` | Update index mappings (add fields, parameters).

Some changes are irreversible without a reindex.

 | [Elasticsearch: Put mapping](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-indices-put-mapping)  
[OpenSearch: Put mapping](https://docs.opensearch.org/latest/api-reference/index-apis/put-mapping/) |
| **Update Settings**  
`PUT /{index}/_settings` | Change the settings for an index.

Some changes can change infrastructure layout and impact runtime.

 | [Elasticsearch: Update Settings](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-indices-put-settings)  
[OpenSearch: Update Settings](https://docs.opensearch.org/latest/api-reference/index-apis/update-settings/) |

### Mapping footguns

Some things for mappings enable incredible things, like highlighting and aggregations (more on aggs later). Here are some specific properties you should use rarely.

| Property | Description & Risks | Docs |
| --- | --- | --- |
| **term\_vectors**  
`"term_vector": "with_positions_offsets"` | Term vectors are used with position offsets to enable highlighting, and can also be used to enable payloads.
Enabling with\_positions\_offsets will increase disk and heap use for the field on which it is enabled by a significant factor.

 | [Elasticsearch: term\_vector](https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/term-vector)  
[OpenSearch: term\_vector](https://docs.opensearch.org/latest/field-types/mapping-parameters/term-vector/) |
| **copy\_to**  
`"copy_to": ["other field", ...]` | Copy\_to allows you to duplicate a field into another for alternate index and query analysis configuration.

Using copy\_to on large text fields to multiple destinations with unoptimized analyzis can grow your index significantly

 | [Elasticsearch: copy\_to](https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/copy-to)  
[OpenSearch: copy\_to](https://docs.opensearch.org/latest/field-types/mapping-parameters/copy-to/) |

Get to know all your mapping field parameters!

-   [Elasticsearch: Mapping Parameters](https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/mapping-parameters)
-   [OpenSearch: Mapping Parameters](https://docs.opensearch.org/latest/field-types/mapping-parameters/index/)

### Settings footguns

Index Settings are vast. There are many of them which you should just leave as defaults unless you know what you are doing. Some settings can be changed on live indices to trigger infrastructure changes with deep implications.

As a general guideline, I encourage you to read through your respective engine's guide:

-   [Elasticsearch: Static Index Settings](https://www.elastic.co/docs/reference/elasticsearch/index-settings/index-modules#_static_index_settings)
-   [OpenSearch: Index Settings](https://docs.opensearch.org/latest/install-and-configure/configuring-opensearch/index-settings/%5D)

| Property | Description & Risks | Docs |
| --- | --- | --- |
| **number\_of\_replicas**  
`"number_of_replicas": _integer_` | This will set the number of primary shard replicas for your index.
Can trigger mass shard movement and recovery (network + IO heavy), degrading search/indexing.

 | [Elasticsearch: Index Settings](https://www.elastic.co/docs/reference/elasticsearch/index-settings/index-modules#_static_index_settings)  
[OpenSearch: Index Settings](https://docs.opensearch.org/latest/install-and-configure/configuring-opensearch/index-settings/) |
| **refresh\_interval**  
`"refresh_interval": _integer_` | Sets the interval time (in seconds) that the engine will make recently added documents available for search.

The default is 1 second, but in large clusters with high ingest rates, consider changing this to a higher number, upwards of 10 seconds maximum.

 | [Elasticsearch: Index Settings](https://www.elastic.co/docs/reference/elasticsearch/index-settings/index-modules#_static_index_settings)  
[OpenSearch: Index Settings](https://docs.opensearch.org/latest/install-and-configure/configuring-opensearch/index-settings/) |

Settings is also where you configure field analysis that your mapping properties will use. In general, avoid ngrams and shingles unless you need them for a specific purpose, as they will significantly increase spatial requirements of the fields using them.

| Property | Description & Risks | Docs |
| --- | --- | --- |
| **N-gram token filter**  
`"type": "ngram"` | Breaks down words into smaller pieces to assisist with partial matching and fuzzy search.
This will grow your index vocabulary in size, impacting the disk and memory requirements for the field.

 | [Elasticsearch: N-gram Token Filter](https://www.elastic.co/docs/reference/text-analysis/analysis-ngram-tokenizer)  
[OpenSearch: N-gram Token Filter](https://docs.opensearch.org/latest/analyzers/token-filters/ngram/) |
| **Shingle token filter**  
`"type": "shingle"` | Generates word n-grams ("shingles") which assists in phrase search.

With the default `output_unigrams` set to `true` as the default, your index vocabulary will grow in size, impacting the disk and memory requirements for the field.

 | [Elasticsearch: Shingle Token Filter](https://www.elastic.co/docs/reference/text-analysis/analysis-shingle-tokenfilter)  
[OpenSearch: Shingle Token Filter](https://docs.opensearch.org/latest/analyzers/token-filters/shingle/) |

Get to know all your analysis types!

-   [Elasticsearch: Text Analysis](https://www.elastic.co/docs/reference/text-analysis/)
-   [OpenSearch: Text Analysis](https://docs.opensearch.org/latest/analyzers/)

### Aggregations

I saved the best for last, because this is a query time footgun that I see all too often. Aggregations are complex counting operations that have high I/O and CPU use, and when used without care will saturate your CPU and make latency terrible for everyone. When serving large corpora at high query loads, be sure to optimize your aggregations and only use where necessary. Also be sure to couple them with strict matching/filter critera in your query to ensure you're not aggregating across too much data.

## Conclusion

Well, that's all for now. Remember, Bonsai is here to take away the pain. Stay green, stay happy, and stay safe out there folks!

_Copyright ©️ Bonsai.io, 2026 · By Max Irwin · Originally published at https://bonsai.io/blog/risky-operations-in-elasticsearch-and-opensearch/ · CC BY-SA 4.0_