The query was re-executed on the primary and replicas, so different documents could be deleted, leading to silently inconsistent replicas (data corruption).

It made upgrades fragile, because a Delete by Query request could leave a query in the transaction log which may not parse correctly after upgrading, or may not execute correctly e.g. if it referred to index aliases that have since been deleted, leading to bugs like this one.

This implementation is necessarily slower, especially if the query deletes many documents. Be sure to test your application if you delete many documents using this API, and consider switching to a different approach where you can
delete whole indices instead.

A minimal Elasticsearch core

Switching to a plugin was not an easy decision: many users were able to use the faster core Delete by Query without issue. Still, the danger was always there, and a non-trivial number of users did hit the serious problems above.

Furthermore, Elasticsearch's core must remain reliable and lean. Any feature which can be built on top of the other core APIs really does not belong in the core, especially if it's buggy. All features in the core should be ironclad, and Delete by Query, despite its popularity and high performance, simply wasn't.

We take resiliency and quality seriously enough to make hard tradeoffs like this one, when necessary.

Deleting a Mapping is gone

However, you can still delete all documents for a given type using the plugin with a Match All Query against that type, or strongly consider changing your approach to use a separate index instead of different types within one index.