OpenSearch vs. Elasticsearch Today

If you learned this engine as Elasticsearch, most of your mental model still works: Lucene segments, shards and replicas, the inverted index, BM25, the cluster-state model, the query DSL. OpenSearch began as a fork of that codebase, so the bones are shared. This page is for porting that mental model forward — it catalogs where OpenSearch has evolved or diverged since the fork, so you stop being surprised by cluster_manager, segment replication, and the _plugins/_* surface.

Discipline: This page describes what OpenSearch has, with the divergence point named. It does not claim what Elasticsearch's current internals look like — those are a separate, independently-evolving codebase, and overclaiming there would be wrong as often as right. Read every row as "OpenSearch has X (since version Y)," not "Elasticsearch lacks X."

The fork point

Because the divergence point is a single known commit (7.10.2), you can often read OpenSearch internals as "7.10-era Lucene/ES architecture plus everything in the tables below." The package names changed from org.elasticsearch.* to org.opensearch.* in a mechanical rename early in the fork; almost every class you'll grep for keeps its short name.

What OpenSearch has built since the fork

Each of these is an OpenSearch capability with a chapter in this book. Frame them as additions/divergences from the 7.10.2 baseline.

Note: Several of these (segment replication, remote store, reader/writer separation) are facets of one larger arc: decoupling durability and search from the local indexing path, so storage and search scale independently. If you internalize that arc, the individual features stop looking like a grab-bag.

RFCs and tracking issues

Cited by full URL so you can read the design rationale firsthand:

For anything else, search the relevant repo's issues with a RFC/[META] label filter rather than trusting a memorized number:

gh issue list --repo opensearch-project/OpenSearch --search "RFC segment replication in:title"
gh issue list --repo opensearch-project/OpenSearch --search "label:RFC"
gh issue list --repo opensearch-project/k-NN --search "RFC in:title"

Naming / terminology differences

The single most common source of "wait, that's not what I typed" when moving from an Elasticsearch mental model. Old names are generally retained as deprecated aliases, so both work, but new code, settings, and docs use the right column.

Warning: "Deprecated alias" means works now, warns, may be removed. When you contribute, use the cluster_manager spelling in new code, settings, tests, and docs — reviewers will ask you to. When you operate a cluster, prefer the new names so you don't carry deprecation debt.

Where the architecture is genuinely the same

So you don't over-rotate: the load-bearing core is shared lineage and behaves the way your Elasticsearch instinct expects.

The shared baseline is 7.10.2-era. Anything that landed in Elasticsearch after the fork is not in OpenSearch (and vice-versa) unless independently re-implemented; the two codebases have diverged for years now.

If you're coming from Elasticsearch, read these chapters

A directed reading path that maps "the thing you already know" to "where OpenSearch differs or has grown."

Practical migration notes

Small things that bite when you point Elasticsearch habits at OpenSearch:

• Config file & env vars: opensearch.yml, not elasticsearch.yml; set OPENSEARCH_INITIAL_ADMIN_PASSWORD for the demo security config.
• Settings names: prefer cluster_manager/cluster.initial_cluster_manager_nodes; cluster_manager_timeout over master_timeout. Old names warn.
• Security is on by default in the standard distribution — your first curl needs -u admin:... -k (TLS + basic auth). security/lab-01-authn-tls.md explains the securityadmin.sh + YAML config flow.
• Clients: use the OpenSearch language clients (opensearch-py, opensearch-java, ...). Some Elasticsearch clients added version checks that reject non-Elasticsearch servers; OpenSearch clients don't.
• Replication strategy is a choice: document replication (classic) vs segment replication is an index setting — pick deliberately based on write-heaviness.
• Version math is independent: OpenSearch major/minor numbers do not line up with Elasticsearch's. "Which Lucene?" is the better cross-reference — grep the build for the Lucene version both sides happen to be on.

Note: Be respectful and precise when you write or talk about the two projects — many contributors work across the ecosystem, and the histories are entangled. State facts (license, fork point, what each has) and cite RFCs; avoid editorializing about motives. This book's job is to make you effective in the OpenSearch codebase.

First contact: the same requests, the OpenSearch way

The fastest way to recalibrate is to run the requests you already know and watch for the differences.

# Security is on by default in the standard distribution: TLS + basic auth.
# (-k accepts the demo self-signed cert; never -k against production.)
curl -sk -u admin:"$OPENSEARCH_INITIAL_ADMIN_PASSWORD" 'https://localhost:9200'

# Who is the elected coordinator? Note the path: cluster_manager, not master.
curl -sk -u admin:"$PW" 'https://localhost:9200/_cat/cluster_manager?v'

# Is this index using segment replication? Look for the replication.type setting.
curl -sk -u admin:"$PW" \
  'https://localhost:9200/my-index/_settings?filter_path=**.replication' | python3 -m json.tool

# Segment-replication lag (empty unless replication.type=SEGMENT):
curl -sk -u admin:"$PW" 'https://localhost:9200/_cat/segment_replication?v'

# Concurrent segment search status (default-on in 3.0):
curl -sk -u admin:"$PW" \
  'https://localhost:9200/_cluster/settings?include_defaults&filter_path=**.concurrent_segment_search'

# Who am I, per the security plugin's authc/authz chain?
curl -sk -u admin:"$PW" 'https://localhost:9200/_plugins/_security/authinfo?pretty'

# Which plugins are installed? (k-NN, security, neural-search, ml-commons, ...)
curl -sk -u admin:"$PW" 'https://localhost:9200/_cat/plugins?v'

One layer deeper on the headline divergences

Related references

• REST Endpoint Map — every _cat/cluster_manager, _cat/segment_replication, _plugins/_* surface this page mentions.
• Lucene File Formats Cheat-Sheet — the shared storage substrate.
• Segment replication, remote-backed storage, concurrent segment search, star-tree, tiered caching, security — the divergences, in depth.