3 ms·

Just learning about OpenSearch. Looks like it's a fork of Elasticsearch from 2021 when Elasticsearch changed licensing model. https://github.com/opensearch-proj

Just learning about OpenSearch. Looks like it's a fork of Elasticsearch from 2021 when Elasticsearch changed licensing model. https://github.com/opensearch-project/OpenSearch https://github.com/opensearch-project/OpenSearch Anyone know if it's still a drop in replacement for Elasticsearch? And how does it compare on performance and features?

__s 1y ago
It is not a drop in replacement (but almost is) 1.x is compatible with ES 7.10
lockhead 1y ago
It's slower on same hardware, but fine, stay away if you need the UI, the Kibana Fork is hellish slow and riddled with bugs.
- darkamaul 1y ago
  It’s slightly more complex that this. Both OpenSearch and Elasticsearch have workflows where they excel. My company did a fairly comprehensive benchmark of the two products [0] if you are interested in comparing performances. [0] https://blog.trailofbits.com/2025/03/06/benchmarking-opensearch-and-elasticsearch/ https://blog.trailofbits.com/2025/03/06/benchmarking-opensea...
Y-bar 1y ago
It's worth noting that in September 2024 Elasticsearch once again returned to a fully open source license (A GPLv3).
- Salgat 1y ago
  Fool me once...
- jsiepkes 1y ago
  But Elastic Search is still open core. So certain "enterprise" functionally will never make it in the OSS version (unlike in OpenSearch).
  - Y-bar 1y ago
    I work in enterprise, a lot of which is B2B, and we use Elastic Search extensively. What's "open core"?
jillesvangurp 1y ago
I maintain a kotlin client for both Elasticsearch and Opensearch (jillesvangurp/kt-search). There are some differences but they are mostly still API compatible for most of the commonly used features. There are some exceptions to this and vector search would be one of those. The feature was added post fork. There are a few other things of course. E.g. search_after works slightly different on both. My client works around that. And there are a lot of newer features on both sides that are annoyingly different. Both have some sql querying capabilities now but they both have their own take on that. Elastic still has the edge on features IMHO. Especially Kibana has a lot more features than Amazon's fork. And on the aggregation front, Elastic has done quite a bit of feature and optimization work in the last few years (that's what powers the dashboards). For performance it depends what you do. But they both heavily lean on Lucene which remains the open source search library both products use. Elastic cloud is a bit better than opensearch in AWS from what I've seen. If you self host and tune, both should be very similar. Elastic also just tagged version 9.0, which uses the same new version of Lucene as Opensearch 3.0. I have support for both new versions in my client already (added that a few weeks ago). It now works with Elasticsearch v7, 8, and 9 and Opensearch 1,2, & 3. A lot of my consulting clients seem to prefer Opensearch lately. That's mainly because of the less complicated licensing and the AWS support. If you have a legacy Elasticsearch setup switching it to Opensearch should be doable (depending on what you use). But expect to reindex all your data. I don't think a direct migration is possible. If you use Elastic's client libraries, you may need to switch to Opensearch specific ones. This is generally a bit painful (package names, feature differences, etc.). That's why I created kt-search a few years ago.
- Salgat 1y ago
  That's what we ended up doing for our migrations. We actually had a bunch of old Elasticsearch 2.3 databases (ancient), so we stood up an OpenSearch database in parallel for each and on service startup did a one-time automatic index and bulk copy over of all the data. So far very happy with OpenSearch.
- simple10 1y ago
  Ah thanks for the detail! Super useful comment.
blueelephanttea 1y ago
> Anyone know if it's still a drop in replacement for Elasticsearch? As you point out it was forked a number of years ago so it started from the same place (7.10). Elasticsearch is now on 9.0+ and has 27,000 more commits than OpenSearch. So I doubt it is a drop-in replacement anymore. I have no idea how many of those 27K commits are key features, but it is clear divergence.
ignoramous 1y ago
> Just learning about OpenSearch. Looks like ... OpenSearch was once a personal search results aggregator conceived at A9 (Amazon's Silicon Valley subsidiary): https://github.com/dewitt/opensearch https://github.com/dewitt/opensearch
- Blackthorn 1y ago
  Sometimes, the same name refers to multiple things.
  - ignoramous 1y ago
    The difference here is, Amazon's repurposing a Trade Mark it owned already for something else entirely.
Macha 1y ago
One thing that Opensearch misses that would have been very nice to have on a recent project is enrich processors (https://www.elastic.co/docs/manage-data/ingest/transform-enrich/set-up-an-enrich-processor https://www.elastic.co/docs/manage-data/ingest/transform-enr...) If you're just using the standard document ingestion and search stuff, yeah, they're mostly compatible. But the fancier features that were part of the paid version in the past or have been recently developed are either not compatible or missing.

__s 1y ago

It is not a drop in replacement (but almost is) 1.x is compatible with ES 7.10

lockhead 1y ago

It's slower on same hardware, but fine, stay away if you need the UI, the Kibana Fork is hellish slow and riddled with bugs.

darkamaul 1y ago
It’s slightly more complex that this. Both OpenSearch and Elasticsearch have workflows where they excel. My company did a fairly comprehensive benchmark of the two products [0] if you are interested in comparing performances. [0] https://blog.trailofbits.com/2025/03/06/benchmarking-opensearch-and-elasticsearch/ https://blog.trailofbits.com/2025/03/06/benchmarking-opensea...

Y-bar 1y ago

It's worth noting that in September 2024 Elasticsearch once again returned to a fully open source license (A GPLv3).

Salgat 1y ago
Fool me once...
jsiepkes 1y ago
But Elastic Search is still open core. So certain "enterprise" functionally will never make it in the OSS version (unlike in OpenSearch).
- Y-bar 1y ago
  I work in enterprise, a lot of which is B2B, and we use Elastic Search extensively. What's "open core"?

jillesvangurp 1y ago

I maintain a kotlin client for both Elasticsearch and Opensearch (jillesvangurp/kt-search). There are some differences but they are mostly still API compatible for most of the commonly used features. There are some exceptions to this and vector search would be one of those. The feature was added post fork. There are a few other things of course. E.g. search_after works slightly different on both. My client works around that. And there are a lot of newer features on both sides that are annoyingly different. Both have some sql querying capabilities now but they both have their own take on that. Elastic still has the edge on features IMHO. Especially Kibana has a lot more features than Amazon's fork. And on the aggregation front, Elastic has done quite a bit of feature and optimization work in the last few years (that's what powers the dashboards). For performance it depends what you do. But they both heavily lean on Lucene which remains the open source search library both products use. Elastic cloud is a bit better than opensearch in AWS from what I've seen. If you self host and tune, both should be very similar. Elastic also just tagged version 9.0, which uses the same new version of Lucene as Opensearch 3.0. I have support for both new versions in my client already (added that a few weeks ago). It now works with Elasticsearch v7, 8, and 9 and Opensearch 1,2, & 3. A lot of my consulting clients seem to prefer Opensearch lately. That's mainly because of the less complicated licensing and the AWS support. If you have a legacy Elasticsearch setup switching it to Opensearch should be doable (depending on what you use). But expect to reindex all your data. I don't think a direct migration is possible. If you use Elastic's client libraries, you may need to switch to Opensearch specific ones. This is generally a bit painful (package names, feature differences, etc.). That's why I created kt-search a few years ago.

Salgat 1y ago
That's what we ended up doing for our migrations. We actually had a bunch of old Elasticsearch 2.3 databases (ancient), so we stood up an OpenSearch database in parallel for each and on service startup did a one-time automatic index and bulk copy over of all the data. So far very happy with OpenSearch.
simple10 1y ago
Ah thanks for the detail! Super useful comment.

blueelephanttea 1y ago

> Anyone know if it's still a drop in replacement for Elasticsearch? As you point out it was forked a number of years ago so it started from the same place (7.10). Elasticsearch is now on 9.0+ and has 27,000 more commits than OpenSearch. So I doubt it is a drop-in replacement anymore. I have no idea how many of those 27K commits are key features, but it is clear divergence.

ignoramous 1y ago

> Just learning about OpenSearch. Looks like ... OpenSearch was once a personal search results aggregator conceived at A9 (Amazon's Silicon Valley subsidiary): https://github.com/dewitt/opensearch https://github.com/dewitt/opensearch

Blackthorn 1y ago
Sometimes, the same name refers to multiple things.
- ignoramous 1y ago
  The difference here is, Amazon's repurposing a Trade Mark it owned already for something else entirely.

Macha 1y ago

One thing that Opensearch misses that would have been very nice to have on a recent project is enrich processors (https://www.elastic.co/docs/manage-data/ingest/transform-enrich/set-up-an-enrich-processor https://www.elastic.co/docs/manage-data/ingest/transform-enr...) If you're just using the standard document ingestion and search stuff, yeah, they're mostly compatible. But the fancier features that were part of the paid version in the past or have been recently developed are either not compatible or missing.