Why supporting OpenSearch is more challanging then expected

Dear Camunda users,

For Camunda 8 with Optimize and Optimize in Camunda 7 we are committed to supporting OpenSearch AWS as an additional environment. By now we have worked for quite some time on this, and I want to share some insights on why this is more challenging than expected.


  • To ease using search engines like OpenSearch or ElasticSearch Client Libraries are used, which translate between our code (Java) and the engine (HTTP and JSON).


  • Release of a dedicated OpenSearch Client - ElasticSearch changed their Client Library not to be compatible with OpenSearch anymore. The OpenSearch community started to develop and release their own Client Library.
  • New design approach for Client libraries - OpenSearch and ElasticSearch both discontinued their “High-Level Java Client Library”, replacing it with a new “Java Client Library”. ElasticSearch argues that they want to “provide a new library that is independent of the Elasticsearch server code and that provides a very consistent and easier-to-use API for all Elasticsearch features”. The OpenSearch community follows this approach in their client.


  • There is a high amount of code to be adjusted, especially for Optimize, which is deeply integrated with ElasticSearch.
  • A re-architecture of how we use the “High-Level Java Client” library to the new way of building queries with the new “Java Clients”.
  • Unforeseeable bugs: The community-maintained OpenSearch “Java Client” contains bugs and does not yet support the full extent of features provided by the search engine.

All this results in significantly more effort and high risks for given commitments. I wish you all a Merry Christmas and a Happy New Year

Tobias (Product Management)