OpenSearch vs Elasticsearch (2026): Is OpenSearch the Same as Elasticsearch? License, Tested Compatibility, AWS vs Elastic Cloud Pricing, and Which to Choose

OpenSearch vs Elasticsearch: OpenSearch is the Apache 2.0 fork of Elasticsearch 7.10.2, created in 2021 after Elastic changed its license, and it is the engine Amazon OpenSearch Service runs. Five years later they are two different products. They still share a core: OpenSearch 3.9.0 and Elasticsearch 9.5.5 both run Lucene 10.5.1, and the same match query with a terms aggregation returned identical hits on both when we ran them side by side. But vectors, SQL, field types, client libraries and log shippers have split. Choose OpenSearch if you want AWS to run it for you, a permissive Apache 2.0 license, or security and anomaly detection without a paid tier. Choose Elasticsearch if you want Elastic's own features (ES|QL, semantic_text, Elastic Security and Observability) or Elastic Cloud on AWS, Azure or Google Cloud. The trap nobody warns you about: Elastic's own tools refuse to talk to OpenSearch. The Elasticsearch Python client raises UnsupportedProductError, Filebeat 9 stops with "could not connect to a compatible version of Elasticsearch", and a snapshot taken on one will not restore on the other, in either direction.

Ethan wanted two things for the shop: real search across its 4,000 products, and one place to keep the order service's logs. The contractor's quote said "Elasticsearch". The AWS console said "OpenSearch". Ethan created a domain, ran pip install elasticsearch, pointed it at the endpoint and got a red error about an "unknown product". "It's the same thing, isn't it?" he asked. Jake didn't look up from his tea. "It was. In 2021."

This guide compares OpenSearch and Elasticsearch on the things that decide real projects: the license you are agreeing to, what is still compatible and what quietly is not, what each costs on AWS and on Elastic Cloud with 2026 prices, which features are free on each side, and how to move data between them. Every compatibility claim below comes from running OpenSearch 3.9.0 and Elasticsearch 9.5.5 next to each other, plus Elasticsearch 7.10.2, the last open-source build both projects share, and pointing each one's clients and tools at the other. Where a fact comes from somewhere else, such as a price or a benchmark, it says so.

Is OpenSearch the same as Elasticsearch?

No, but it started as the same code. Here is the short history, because it explains almost every difference you will meet.

• Before 2021, Elasticsearch (the search engine) and Kibana (its web interface) were Apache 2.0 open source, with extra paid features from Elastic on top. AWS sold a managed version called Amazon Elasticsearch Service.
• In 2021, with release 7.11, Elastic moved Elasticsearch and Kibana to a dual license: the Server Side Public License (SSPL) or the Elastic License. Neither is an open-source license in the usual sense, and the Elastic License forbids offering the software to others as a managed service, which was aimed squarely at cloud providers.
• AWS and others forked the last Apache 2.0 versions, Elasticsearch 7.10.2 and Kibana 7.10.2, and called the result OpenSearch and OpenSearch Dashboards. Amazon Elasticsearch Service became Amazon OpenSearch Service the same year. That is the moment people mean when they search "Elasticsearch is now OpenSearch": on AWS, it is.
• OpenSearch is now a Linux Foundation project, not an AWS product, with its own release train: 3.5.0 in February 2026, 3.9.0 in September, and 3.10.0 scheduled for November 17, 2026.
• Elastic added AGPLv3 in 2024 as a third license option for the free parts of the Elasticsearch and Kibana source code, so Elasticsearch can again be called open source. Elasticsearch 9.5.5 is the current release.

So when you ask "is OpenSearch and Elasticsearch the same?", the honest answer is: same ancestor, same Lucene library underneath, same basic REST API and query language, and five years of separate development on everything else. Think of them like two languages that split from one parent: you can read most of the other one's simple sentences, but you cannot hand in your homework in it.

"So which one did the contractor mean?" Ethan asked. "Probably neither on purpose," Jake said. "People still say Elasticsearch the way they say Kleenex."

OpenSearch vs Elasticsearch: side by side

Is Elasticsearch open source? The license story in plain English

This is the question most people type first, and the answer changed twice, so it is worth getting exactly right.

Elasticsearch today: the free parts of the source code are available under three licenses, and you pick one: AGPLv3 (an approved open-source license, added in 2024), SSPL 1.0, or the Elastic License 2.0 (ELv2). The ready-made downloads and Docker images ship under the Elastic License. So yes, Elasticsearch is open source again if you take the AGPL route, and "source available" if you just download it.

Is Elasticsearch free for commercial use? For most companies, yes. Under the Elastic License you can run it inside your business, build it into your own product and sell that product. ELv2 has three limits, and they are short enough to read in full:

1. You may not provide the software to third parties as a hosted or managed service where users get access to a substantial set of its features. Running search inside your app is fine; selling "Elasticsearch as a service" is not.
2. You may not move, change, disable or circumvent the license key functionality, or remove functionality the key protects. In plain terms: no unlocking the paid features yourself.
3. You may not alter, remove or obscure Elastic's licensing, copyright or other notices.

If you choose AGPLv3 instead, the trade is different: you can do almost anything, including offering it as a service, but if you modify the code and let users interact with it over a network, you must offer them your modified source. Most teams that are not reselling search never notice any of this.

OpenSearch: Apache 2.0, with no license keys and no paid tier inside the code. You can host it, sell it as a service, fork it or embed it. The plugins that cost money on Elastic's side (fine-grained security, anomaly detection, cross-cluster replication) are part of the free distribution.

Jake's rule of thumb for the shop: "If you're not planning to sell search to other companies, either license is fine. Choose on features and hosting, not on the license argument."

What still works on both (we ran them side by side)

We ran OpenSearch 3.9.0 and Elasticsearch 9.5.5 as single-node containers with security switched off, created the same index on both, loaded the same three documents and sent each one identical requests. Here is what is still shared.

The basic query DSL is the same. This index and search ran unchanged on both engines:

PUT /posts
{"mappings": {"properties": {
  "title":   {"type": "text"},
  "service": {"type": "keyword"},
  "views":   {"type": "integer"}}}}

POST /posts/_search
{"query": {"bool": {
   "must":   [{"match": {"title": "lambda"}}],
   "filter": [{"range": {"views": {"gte": 100}}}]}},
 "aggs": {"by_service": {"terms": {"field": "service"}}}}

Both returned the same two hits in the same order ("Lambda layer not found", then "Lambda timeout after 3 seconds") and the same bucket (lambda, 2 documents). Both engines run Lucene 10.5.1, so scoring for ordinary text search is the same machinery. The common field types text, keyword, integer, date, plus wildcard, constant_keyword and match_only_text, were accepted by both.

Reindex from remote works in both directions. OpenSearch 3.9 pulled an index straight out of Elasticsearch 9.5.5 with _reindex, Elasticsearch pulled one back out of OpenSearch, and OpenSearch also copied an index from Elasticsearch 7.10.2. This is the migration path that works, and it is covered step by step in the migration section.

The OpenSearch Python client talks to Elasticsearch. opensearch-py 3.2.0 ran info(), a search and an index call against Elasticsearch 9.5.5 without complaint. That surprised us, because the reverse is blocked, as the next section shows.

How to tell which one you are talking to: send GET /. OpenSearch answers with "distribution" : "opensearch" inside version, the tagline "The OpenSearch Project", and an X-OpenSearch-Version header. Elasticsearch answers with "build_flavor" : "default", the tagline "You Know, for Search", and an X-Elastic-Product: Elasticsearch header.

Where they broke apart: clients, Filebeat and Kibana

This is where most migrations and most "it's the same thing" assumptions fail, so here are the exact results.

The official Elasticsearch clients refuse OpenSearch. Since version 7.14, Elastic's clients check that the server really is Elasticsearch before sending anything. Against OpenSearch 3.9.0, elasticsearch-py 9.5.1 and 7.14.0 both stopped at the first call:

elasticsearch.UnsupportedProductError: The client noticed that the server is not
Elasticsearch and we do not support this unknown product

Version 7.13.4, the last release before the check, still worked against OpenSearch. The check also bites legacy clusters: against the open-source Elasticsearch 7.10.2 build (the OSS line AWS still offers for legacy Elasticsearch domains), client 7.14.0 failed with "The client noticed that the server is not a supported distribution of Elasticsearch", and only 7.13.4 connected. The fix is not to pin an old client forever; switch to the OpenSearch client for your language:

pip uninstall -y elasticsearch
pip install opensearch-py

from opensearchpy import OpenSearch
client = OpenSearch("http://localhost:9200")
print(client.info()["version"]["number"])     # 3.9.0
print(client.search(index="posts", body={"query": {"match": {"title": "lambda"}}})["hits"]["total"])

On Amazon OpenSearch Service, the client also has to sign requests with SigV4 unless you use fine-grained access control with a username and password; the "anonymous is not authorized" guide shows both. Java teams using Spring have Spring Data OpenSearch, a separate project from Spring Data Elasticsearch.

Filebeat 9 refuses OpenSearch. We pointed Filebeat 9.5.5 at both engines. Against Elasticsearch it connected at once. Against OpenSearch 3.9.0 it retried forever with:

Failed to connect to backoff(elasticsearch(http://os39:9200)): Connection marked as failed
because the onConnect callback failed: could not connect to a compatible version of
Elasticsearch: 400 Bad Request: ... "Invalid index name [_license], must not start with '_'."

Filebeat asks for Elastic's _license API, OpenSearch has no such API and reads _license as an index name, and the connection is marked failed.

Even old Filebeat no longer works with OpenSearch 3. The usual advice is "use Filebeat OSS 7.10.2". We tried it. It connected, then every bulk request failed with Action/metadata line [1] contains an unknown parameter [_type]: it sees version 3.9.0, treats the server as an old Elasticsearch, and sends the _type field that OpenSearch 3 no longer accepts. The OpenSearch 2.x switch that used to make OpenSearch pretend to be 7.10.2, compatibility.override_main_response_version, is gone too: OpenSearch 3.9 rejected it as "not recognized". For OpenSearch 3, use a shipper that knows it. Fluent Bit 5.1.5 worked first time with its opensearch output:

[INPUT]
    Name               tail
    Path               /var/log/app.log
[OUTPUT]
    Name               opensearch
    Match              *
    Host               my-opensearch-host
    Port               9200
    Index              app-logs
    Suppress_Type_Name On

Data Prepper (the OpenSearch project's own collector), Logstash with the logstash-output-opensearch plugin, and OpenSearch Ingestion on AWS are the other common choices.

Kibana and OpenSearch Dashboards are separate products. OpenSearch Dashboards started as Kibana 7.10.2 and has gone its own way, so use the interface that matches your engine. Kibana is to Elasticsearch what Dashboards is to OpenSearch: the window, not the store. Ethan had been trying to install Kibana in front of his OpenSearch domain, which already came with Dashboards built in.

Field types and query languages that exist on only one side

Mappings are where copied tutorials break. We created a one-field index with each of these types on both engines. The results:

The 405 from OpenSearch on /_query is a confusing one: OpenSearch reads _query as an index name and tells you only GET, PUT, HEAD and DELETE are allowed. It is not saying your query is wrong; it is saying the whole API does not exist there.

Both SQL dialects returned the same answer for SELECT service, COUNT(*) FROM posts GROUP BY service, and the two piped languages look alike too. ES|QL is FROM posts | STATS c = COUNT(*) BY service; PPL is source=posts | stats count() by service. If your team writes dashboards or alerts in one, plan to rewrite them for the other.

OpenSearch vs Elasticsearch for vector search

Both engines are now sold as vector databases, and both handled a three-dimensional test index with cosine similarity, returning the same two nearest neighbors. But the request shapes are different, and each engine rejected the other's syntax.

# Elasticsearch: dense_vector field, top-level "knn" section
PUT /vec  {"mappings": {"properties": {"v": {"type": "dense_vector", "dims": 3, "similarity": "cosine"}}}}
POST /vec/_search
{"knn": {"field": "v", "query_vector": [1, 0, 0], "k": 2, "num_candidates": 10}}

# OpenSearch: knn_vector field, index.knn setting, "knn" inside "query"
PUT /vec  {"settings": {"index.knn": true},
           "mappings": {"properties": {"v": {"type": "knn_vector", "dimension": 3, "space_type": "cosinesimil"}}}}
POST /vec/_search
{"size": 2, "query": {"knn": {"v": {"vector": [1, 0, 0], "k": 2}}}}

Send the Elasticsearch form to OpenSearch and you get Unknown key for a START_OBJECT in [knn]. Send the OpenSearch form to Elasticsearch and you get [knn] unknown field [v]. Vector code is the least portable part of either engine.

How they differ beyond syntax:

• Elasticsearch leans on convenience: semantic_text fields create embeddings for you through an inference endpoint, and Elastic ships its own models (ELSER, plus the Jina AI models Elastic now owns). The managed ELSER and e5 models on Elastic's machine learning nodes are a Platinum-tier feature.
• OpenSearch leans on choice of engine: the k-NN plugin supports the Faiss and Lucene engines, neural search pipelines call an embedding model you connect, and on AWS you can wire it to Amazon Bedrock. Amazon OpenSearch Service also bills separate OCUs for features such as vector index acceleration ($0.24 per OCU-hour in US East).

If you are building retrieval for an AI app on AWS, also compare the managed route: Bedrock Knowledge Bases can use OpenSearch Serverless as their vector store, so you may never write a k-NN query yourself. For small corpora, pgvector on the PostgreSQL you already run is often enough.

AWS OpenSearch vs Elasticsearch: what Amazon OpenSearch Service runs

"AWS OpenSearch vs Elasticsearch" usually means one of two questions: can I run Elasticsearch on AWS, and is Amazon's service the same thing? Here is what the service actually offers.

• OpenSearch versions: 3.5, 3.3 and 3.1, 2.19 down through 2.3, and 1.3 back to 1.0. AWS trails the open-source project: OpenSearch 3.9.0 is out, but the newest version on the managed service is 3.5.
• Legacy Elasticsearch: Elasticsearch OSS up to 7.10, the final open-source Elasticsearch release. There is no Elasticsearch 8 or 9 on Amazon OpenSearch Service, and there never will be under the Elastic License.
• Extended Support: older engine versions move into Extended Support, billed at $0.0065 per normalized instance hour on top of the normal instance price. The OpenSearch cost guide covers which versions and how to get out.
• Two ways to buy it: managed domains (you choose instance types, node counts and EBS storage) and OpenSearch Serverless (collections that scale in OpenSearch Compute Units, OCUs, each about 6 GiB of memory plus matching vCPU).

If you need Elasticsearch 9 features on AWS, you have three options: Elastic Cloud running in an AWS Region (bought from Elastic directly or through AWS Marketplace), self-managed Elasticsearch on EC2 instances, or Elastic Cloud on Kubernetes (ECK) on EKS. All three keep your data in AWS; none of them is an AWS-managed service, so support, upgrades and the bill come from Elastic or from you.

Amazon OpenSearch Service is not "Elasticsearch with a new name" any more. It is OpenSearch with AWS extras on top: IAM and SigV4 authentication, VPC access, UltraWarm and cold storage tiers, Multi-AZ with Standby, automated snapshots to S3, zero-ETL integrations and the OCU-billed add-ons. Metrics land in Amazon CloudWatch like everything else in your account.

"So if we stay on AWS, we're on OpenSearch whether we like it or not," Ethan said. "Unless you pay Elastic," Jake said. "Which is a real option, just not a free one."

OpenSearch vs Elasticsearch pricing in 2026

Both engines are free to download and run yourself. You pay for hosting, and on Elastic's side, for the paid feature tiers. Here are the managed prices that matter, US East (N. Virginia), October 2026.

Two worked examples on the AWS side, so you can see how a bill is built:

Dev domain, 1 x t3.small.search + 10 GB gp3:
  0.036 x 730 = $26.28   +   10 x 0.122 = $1.22        = $27.50 a month

Two-zone starter, 2 x m7g.large.search + 2 x 100 GB gp3:
  2 x 0.135 x 730 = $197.10   +   200 x 0.122 = $24.40  = $221.50 a month
  (before dedicated master nodes, which production domains should add)

Read the comparison carefully, because the two sides do not price the same unit. Elastic's "from $99" is a small two-zone deployment with the Standard feature set; AWS's $221.50 is two general-purpose nodes with 8 GiB of memory each. OpenSearch Serverless collection groups can now scale to zero OCUs when idle if you set the minimum to 0, which makes spiky or rarely used collections much cheaper than they used to be; a collection that is busy around the clock pays for its OCUs every hour, $175.20 a month for each one. The smallest honest OpenSearch cluster walks through the production minimum on AWS, including masters and Multi-AZ.

Self-hosting is free in license terms for both, but not free: you pay for the servers, the disks, the backups and the person who upgrades the cluster. For logs specifically, compare against what CloudWatch Logs ingestion would cost before building a search cluster at all.

Free vs paid features: security, machine learning, alerting

The feature gap is where "OpenSearch vs Elasticsearch free" really gets decided, because the free tiers are not the same size.

Free in Elasticsearch (self-managed): the full engine and Kibana, native username and password login, role-based access control, TLS encryption, Discover and dashboards, alerting, lexical and vector search, Elastic Agent and Fleet, out-of-the-box threat detection rules with case management, and APM, logs and metrics views.

Elasticsearch Platinum and above (paid): single sign-on, LDAP and Active Directory, field- and document-level security, audit logging, machine learning anomaly detection, Elastic's ELSER and e5 models on ML nodes, and cross-cluster replication. Enterprise adds searchable snapshots, which let you search years of data stored cheaply in S3.

Free in OpenSearch, all of it: the security plugin with fine-grained access control (index, document and field level), audit logs, SAML and LDAP, anomaly detection, alerting, cross-cluster replication, index state management, the SQL and PPL plugins, security analytics with detection rules, and the k-NN vector engine.

Read that list and the pattern is plain: a team that needs document-level security or anomaly detection on a budget gets them free with OpenSearch, and pays Elastic for them otherwise. A team that wants the most polished observability or security product, with Elastic's support behind it, is paying for exactly what the extra money buys. Neither is a trick; they are different business models. You will rarely regret choosing on the features you need this year rather than the ones you might need someday.

OpenSearch vs Elasticsearch performance: whose benchmark to trust

You will find benchmarks that crown each side, and you should know who paid for each.

• Elastic, 2023: Elastic published a comparison of Elasticsearch 8.7 against OpenSearch 2.7 that claimed Elasticsearch was 40% to 140% faster across text, sorting, date histogram, range and terms workloads, and used 37% less disk with default settings. Elastic also reported vector search results in 2024 in its favor.
• Trail of Bits, 2025, commissioned by AWS: a four-month study that reported OpenSearch 2.17.1 1.6 times faster than Elasticsearch 8.15.4 on the "Big5" workload and 11% faster on vector search, by geometric mean of query times.

Both are honest about what they measured and both were paid for by an interested party. Both are also several releases old: today's versions run the same Lucene 10.5.1, which narrows the gap for plain text search, and each release moves the numbers again. The only benchmark that matters is your data, your queries and your hardware. Elastic's Rally and the OpenSearch Benchmark tool both replay real workloads; load a day of your own logs or your own product catalog, run your ten most common queries on each, and compare latency and disk use. An afternoon of that beats any published chart.

For a small shop, Jake's view was simpler: "At 4,000 products, both will answer in a few milliseconds. Your bottleneck is the product photos, not the search engine."

Elasticsearch vs OpenSearch for logs and SIEM (Graylog included)

Log analytics and security monitoring are where most clusters live, and the tooling decides more than the engine does.

Elastic as a SIEM: Elastic Security is a full product: detection rules, timelines, case management, endpoint protection and an AI assistant, all inside Kibana. The free tier includes threat detection and case management; machine learning detections, entity risk scoring, behavioral ransomware protection and third-party ticketing integrations need Platinum. Data arrives through Elastic Agent or Beats, which, as tested above, will not ship to OpenSearch.

OpenSearch as a SIEM: OpenSearch Security Analytics ships detection rules, findings, correlations and alerting in the free distribution, and its anomaly detection plugin is also free. It is less of a finished product and more of a set of parts, which is why many teams run another tool on top of it.

Graylog: Graylog's current releases are built around OpenSearch. Graylog 7.2 supports self-managed OpenSearch from 1.1.x up to 3.7.x (OpenSearch 3 only when no index was created before OpenSearch 2.0), or its own Data Node, which runs OpenSearch for you. Elasticsearch is not on Graylog's compatibility list at all, so "Graylog OpenSearch vs Elasticsearch" has a one-word answer today: OpenSearch.

Other tools to compare while you are here: Splunk is a commercial platform priced well above either engine but with the most mature SIEM content; Grafana Loki indexes only labels, not the full log text, so it is far cheaper to run and far weaker at free-text search. If your logs already live in CloudWatch, metric filters and Logs Insights may cover alerting without a search cluster at all.

Solr, Splunk, Kendra, CloudSearch and other alternatives

Searches like "solr vs elasticsearch vs opensearch" and "kendra vs opensearch vs elasticsearch" show many people are choosing among more than two. In one line each:

• Apache Solr: also built on Lucene and Apache 2.0 licensed. Strong for classic document and e-commerce search, with a smaller ecosystem for logs and dashboards.
• Splunk: commercial log analytics and SIEM. Rich and expensive; not an open-source alternative.
• Amazon Kendra: managed enterprise search over documents with connectors to sites, wikis and drives. You do not manage indexes or queries in the same way, and you pay per index rather than per node.
• Amazon CloudSearch: closed to new customers since July 25, 2024. Existing users keep it, and AWS points them to Amazon OpenSearch Service.
• Meilisearch and Algolia: typo-tolerant search for apps and websites, much simpler to set up, not built for log analytics.
• Redis and PostgreSQL: both can do search and vectors well enough for small datasets you already store there.

If you came here looking for an "open source version of Elasticsearch" or an "Elasticsearch open source alternative", the direct answer is OpenSearch (same API family, Apache 2.0) or Elasticsearch itself under AGPLv3. Solr is the alternative that does not share the codebase.

Moving from Elasticsearch to OpenSearch (or back), step by step

Most guides say "take a snapshot and restore it". In 2026 that fails, and we checked every direction:

• Elasticsearch 9 snapshot into OpenSearch 3.9: OpenSearch could not even list the repository: repository_exception ... Failed to parse object: unknown field [uuid] found.
• OpenSearch 3.9 snapshot into Elasticsearch 9: refused with the snapshot was created with version [9.5.6-[137307827]] which is higher than the version of this node. Elasticsearch misreads OpenSearch's version number as a future Elasticsearch release.
• Elasticsearch 7.10.2 snapshot into OpenSearch 3.9: listed fine, then the snapshot has an unknown or unsupported version and cannot be restored. OpenSearch 3 only reads indices created on OpenSearch 2.0 or later.

What works is reindex from remote: the target cluster reads documents from the source over HTTP and writes them into a new index. Here is the order that keeps you safe:

1. Inventory first. List indices, mappings, ingest pipelines, client libraries, shippers and dashboards. Search the mappings for dense_vector, flattened and semantic_text; those need translating.
2. Create the target indices yourself with translated mappings (for example dense_vector to knn_vector with "index.knn": true, flattened to flat_object). Reindex copies documents, not your carefully tuned settings.
3. Allow the source host on every target node. It is a static setting, so it goes in opensearch.yml (or elasticsearch.yml) and needs a restart: reindex.remote.allowlist: "old-cluster:9200" on OpenSearch, reindex.remote.whitelist on Elasticsearch.
4. Run the reindex one index at a time, then compare counts with GET /index/_count on both sides.
5. Switch clients and shippers to the target's own libraries (see the client section above), then point an alias at the new index so the cutover is a single change you can undo.
6. Rebuild dashboards and alerts. OpenSearch Dashboards forked from Kibana 7.10.2, so saved objects from newer Kibana versions are not something to count on importing.

POST /_reindex?wait_for_completion=true
{
  "source": {"remote": {"host": "http://old-cluster:9200"}, "index": "posts"},
  "dest":   {"index": "posts-v2"}
}
# 200 {"total": 4, "created": 4, "failures": []}

On Amazon OpenSearch Service, you cannot edit opensearch.yml; the service has its own remote reindex feature instead. It copies from other domains or from self-managed OpenSearch and Elasticsearch clusters, as long as the source is a lower or equal major version (Elasticsearch counts as lower than OpenSearch, so Elasticsearch to OpenSearch is allowed), the source is reachable from the domain, and your data nodes are not T2 or T3 instances, which cannot use remote reindex at all. For very large clusters, the OpenSearch project's Migration Assistant automates the backfill and live traffic capture.

Which to choose: five questions

If you are still undecided, answer these in order. The first "yes" usually decides it.

1. Do you want AWS to run it, inside your AWS bill, with IAM and VPC built in? Choose OpenSearch (Amazon OpenSearch Service or Serverless).
2. Do you need an Elastic-only feature such as ES|QL, semantic_text, Elastic Security's full SIEM, or Elastic's observability apps? Choose Elasticsearch, on Elastic Cloud or self-managed.
3. Do you need document-level security, SSO or anomaly detection without paying for a tier? Choose OpenSearch.
4. Are you building a product that offers search to other companies as a service? Choose OpenSearch, or read the AGPLv3 obligations carefully before choosing Elasticsearch.
5. Does your team already run Beats, Elastic Agent or Kibana everywhere? Staying on Elasticsearch saves a migration of every shipper and dashboard.

If none of these apply, start where your data already lives. On AWS that is usually OpenSearch; on Azure or Google Cloud it is usually Elastic Cloud. Whatever you choose, use that engine's own client libraries from day one, and do not plan your backups around moving snapshots between the two.

Ethan went with OpenSearch Service: the shop runs entirely on AWS, the product catalog needs plain text search with a few filters, and the logs needed one dashboard and two alerts. "What would make you switch?" he asked. Jake thought about it. "If we ever hire a security team that wants Elastic Security. Until then, no."

Errors you will hit, and what each one means

UnsupportedProductError: The client noticed that the server is not Elasticsearch

You are using an Elasticsearch client (7.14 or newer) against OpenSearch. Install the OpenSearch client for your language (opensearch-py, @opensearch-project/opensearch, opensearch-java) and change the import.

The client noticed that the server is not a supported distribution of Elasticsearch

Same check, against an open-source Elasticsearch 7.10 build such as a legacy AWS Elasticsearch domain. Client 7.13.4 still connects, but the real fix is upgrading the domain to OpenSearch and switching clients.

could not connect to a compatible version of Elasticsearch: Invalid index name [_license]

Filebeat or another Beat is pointed at OpenSearch. Beats ask for Elastic's license API, which OpenSearch does not have. Ship with Fluent Bit, Data Prepper or Logstash with the OpenSearch output.

Action/metadata line [1] contains an unknown parameter [_type]

An old shipper or client (Filebeat OSS 7.10.2, for example) is writing to OpenSearch 3, which no longer accepts _type. Upgrade to a shipper that supports OpenSearch, or in Fluent Bit set Suppress_Type_Name On.

No handler for type [dense_vector] declared on field

An Elasticsearch mapping on OpenSearch. Use knn_vector with "dimension" and set "index.knn": true; for flattened, use flat_object.

The mapper type [knn_vector] declared on field does not exist

An OpenSearch mapping on Elasticsearch. Use dense_vector with "dims"; for flat_object, use flattened.

repository_exception: Failed to parse object: unknown field [uuid] found

OpenSearch is reading an Elasticsearch 8 or 9 snapshot repository. Snapshots are not portable between the two; use reindex from remote.

the snapshot was created with version [9.5.6-[...]] which is higher than the version of this node

Elasticsearch is reading an OpenSearch snapshot and misreading its version number. Again, reindex from remote instead.

[host:9200] not allowlisted in reindex.remote.allowlist

Add the source host and port to reindex.remote.allowlist in opensearch.yml on every node and restart; it cannot be changed through the cluster settings API.

persistent setting [compatibility.override_main_response_version], not recognized

That OpenSearch 1.x and 2.x switch made the server report version 7.10.2 to old tools. OpenSearch 3.9 does not have it, so replace the old tool instead.

Frequently asked questions

The shop's search went live a week later on a two-node OpenSearch domain. Ethan swapped one import line in the order service, replaced the Filebeat config he had copied from a tutorial with a short Fluent Bit config, and deleted the half-installed Kibana. Jake asked him to write one thing on the wiki: "We run OpenSearch. Do not pip install elasticsearch." Ethan underlined it twice.

Revision note. Written October 23, 2026. "Look before you leap," the proverb says; restore one test snapshot before you build a migration plan around it.