OpenSearch and the fork

Ads name both, often in the same line, and the question behind it is whether you know they are the same codebase five years apart — and which half of the difference actually affects your code.

Verified 2026-08

Verified 2026-08. Re-check before quoting a licence; this area has moved twice already.

What happened, in order

The shape is identical to Redis → Valkey and Terraform → OpenTofu: a licence change aimed at cloud vendors, answered with a foundation-governed fork. See Valkey.

The 2024 events are the ones that date a candidate. Saying “Elasticsearch isn’t open source” has been wrong since AGPL was added; saying “OpenSearch is just an AWS project” has been wrong since the Linux Foundation took it.

Licence, and why AGPL is not a non-issue

Apache 2.0 is permissive. AGPLv3 is copyleft over a network, which is the practical difference: modify Elasticsearch and expose it as a service and the obligation to publish your modifications attaches. Most teams run it unmodified and are unaffected — but legal review in a product company frequently lands on Apache 2.0 for exactly this reason, and being able to say why is the senior answer.

What actually differs in your code

Almost nothing, and that is the useful part:

# Elasticsearch
from elasticsearch import Elasticsearch
es = Elasticsearch("https://localhost:9200", api_key=KEY)

# OpenSearch — same shape, different package
from opensearchpy import OpenSearch
os_ = OpenSearch(hosts=[{"host": "localhost", "port": 9200}],
                 http_auth=("admin", PASSWORD))

Query DSL, mappings, aggregations and the bulk API are the same at the level these notes cover — everything in Elasticsearch — Query DSL and BM25 Scoring and Elasticsearch — Aggregations applies to both.

Gotcha: use the matching client. elasticsearch-py 8+ refuses to talk to OpenSearch — it sends a product-verification header and errors with “the client noticed that the server is not Elasticsearch”. That check exists deliberately; pinning elasticsearch-py<7.14 to defeat it is a workaround people reach for and should not.

Where they have genuinely diverged is the layer above search:

Security is the one worth naming: field- and document-level security is a paid Elastic feature and a free OpenSearch one. In a regulated tenant that single row can decide the choice.

// OpenSearch: role-based field masking, no subscription.
{
  "index_permissions": [{
    "index_patterns": ["patients*"],
    "masked_fields": ["nhs_number"],
    "dls": "{\"term\": {\"tenant\": \"acme\"}}"
  }]
}

dls filters which documents a role sees and masked_fields hashes values it may not read. Building the same thing yourself — a filter every query must remember to apply — is the alternative, and it fails the first time someone forgets.

Choosing

Usually you do not — the platform decided. Amazon OpenSearch Service is the managed offering on AWS, so an AWS-native shop lands on OpenSearch by default, and the same is true in reverse for Elastic Cloud.

What would change it:

• Licence policy. An organisation that will not take AGPL dependencies.
• A specific feature. ES|QL and Elastic’s newer relevance work versus OpenSearch’s ML Commons and free security.
• Existing Kibana dashboards, which do not port cleanly.

And for vector search specifically, both are viable but neither is the obvious answer — see Elasticsearch — Vector Search and kNN and Vector Databases.

Related

• Elasticsearch — Python Client and Production Pitfalls — the client patterns, both flavours
• Elasticsearch — Vector Search and kNN — k-NN on either
• Valkey — the same story, different project
• OpenTofu and the Terraform licence split — and again