Once you have decided to run ElasticPress for WordPress search, an obvious question follows: can the search engine behind it be OpenSearch, the Apache-licensed fork, instead of Elasticsearch? It is a reasonable thing to want. OpenSearch has a permissive license and AWS sells it as a managed service. But the honest answer is not the one most "Elasticsearch vs OpenSearch" articles give. ElasticPress officially supports Elasticsearch, and not OpenSearch. Here is the real status, why it is the way it is, and what to actually run.
The short answer
Run Elasticsearch. ElasticPress is built and tested against Elasticsearch, and that is the only backend its requirements list. 10up's own compatibility documentation states that ElasticPress does not officially support OpenSearch and does not recommend using OpenSearch in production. Basic functionality may work, and people do run the combination, but it is unofficial and unsupported. If search matters enough to add ElasticPress at all, run it on the engine ElasticPress is actually supported on.
Why the question comes up
The reason anyone asks is licensing. Elasticsearch was Apache 2.0 open source for years. In 2021, Elastic changed the license to a dual SSPL and Elastic License model, which is not OSI-approved open source. AWS forked the last Apache 2.0 release, Elasticsearch 7.10, into OpenSearch, which stays Apache 2.0. In 2024, Elastic added an AGPLv3 option, so recent Elasticsearch is open source again under the AGPL.
So both engines are open source today, under different licenses, and OpenSearch carries the more permissive one. That, plus AWS OpenSearch Service being an easy managed offering, is why "can I just use OpenSearch?" is such a common question. The licensing case for OpenSearch is real. The ElasticPress support case is not.
What ElasticPress officially supports
ElasticPress's published requirements list one search backend: Elasticsearch (version 5.2 and up). OpenSearch is not in the requirements at all. 10up's compatibility documentation is explicit that ElasticPress does not officially support OpenSearch in the current plugin version, that basic functionality may be possible but is not guaranteed, and that they do not recommend OpenSearch in production.
The concrete reason is a version-number collision. ElasticPress assumes it is talking to an Elasticsearch instance and branches its behavior on the reported version. OpenSearch reports its own version numbers, which do not line up with Elasticsearch's, so ElasticPress can misread what engine and capabilities it is dealing with. That mismatch is the root of the "may work, may not" uncertainty.
Can you run OpenSearch with ElasticPress anyway?
Unofficially, yes, with caveats. Because the core problem is the version mismatch, the common workaround is a code snippet that forces ElasticPress to treat the cluster as a specific Elasticsearch mapping version compatible with your OpenSearch release. There is also a third-party plugin, elasticpress-on-opensearch, built specifically to bridge the compatibility gap.
Both are real options and both come with the same warning: you are running an unsupported combination. A workaround that holds today can break on the next ElasticPress release, the next OpenSearch release, or a mapping change, and when it does, the supported answer from 10up is "use Elasticsearch." If you go this route, treat it as a deliberate, monitored exception, pin your versions, and test search hard after every update.
What this means for AWS users
This is the catch that surprises people. On AWS, the easy managed search option is AWS OpenSearch Service, and it is tempting precisely because IAM and VPC integration are built in. But AWS OpenSearch Service is OpenSearch, so it inherits the unsupported status above. Choosing it for an ElasticPress site is choosing the unofficial path.
For a supported setup on AWS, the options are running Elasticsearch yourself on EC2, or using Elastic Cloud (which runs on AWS among other providers). Neither is as frictionless as clicking "create domain" in the AWS console, but both keep you on the engine ElasticPress is built for.
Comparison
| Factor | Elasticsearch | OpenSearch |
|---|---|---|
| ElasticPress official support | Yes, the documented backend | No, not officially supported |
| Production recommendation | Recommended | Not recommended by 10up |
| Works at all | Yes | Basic functionality may work, with a workaround |
| Version reporting | Matches what ElasticPress expects | Mismatched, the core compatibility issue |
| License | AGPLv3 (and Elastic License options) | Apache 2.0 |
| Managed hosting | Elastic Cloud, some WP hosts | AWS OpenSearch Service and others |
| Risk on updates | Normal | A workaround can break at any release |
The verdict
For any production WordPress or WooCommerce site, run Elasticsearch. It is the backend ElasticPress is built, tested, and supported on, and "supported" is worth a great deal when search is a revenue or engagement feature. OpenSearch's licensing is genuinely more permissive, and if that matters enough to your organization you can run the unofficial combination with a version-mapping workaround or the elasticpress-on-opensearch plugin, eyes open, versions pinned, search tested after every update. That is a deliberate exception, not a default.
This may change. ElasticPress's compatibility page is where 10up would announce official OpenSearch support if it ships, so check it before assuming today's status still holds. If you have not yet decided whether to run ElasticPress at all, start with Do I Need ElasticPress? and ElasticPress vs MySQL FULLTEXT. For a store, search is one layer of a larger job; How to Optimize WooCommerce covers the rest.
