OpenSearch's Rise: 9.5x Faster Search, Read-Write Separation, and True Open Source

Origin and Governance Shift

OpenSearch began in January 2021 when Elastic changed Elasticsearch and Kibana licenses from Apache 2.0 to SSPL + Elastic License v2. SSPL requires that if you offer the software as a service, you must open-source your entire management stack. AWS responded by forking Elasticsearch 7.10.2 (the last Apache 2.0 version) and naming it OpenSearch, releasing 1.0 in July 2021.

The pivotal turn came in September 2024 when AWS transferred governance to the Linux Foundation, establishing the OpenSearch Software Foundation with founding members AWS, SAP, Uber, Aiven, and Canonical. From that point, OpenSearch and Elasticsearch diverged completely. In August 2024 Elastic added AGPLv3 as a third licensing option, which imposes a "network use equals distribution" clause requiring service providers to open-source their code.

Core Architecture: Five-Layer Abstraction and Inverted Index

OpenSearch Core's architecture comprises five core concepts: Cluster , Node , Index , Shard , and Document . Node types define cluster responsibilities:

Data nodes : store index data, handle ingestion, search, and aggregation.

Master nodes : manage cluster-level operations.

Coordinating nodes : receive client requests and route to data nodes.

Search capability is built on Apache Lucene , whose core data structure is the inverted index — a mapping from each term to the list of documents containing it, enabling instant lookup of documents for a query term.

Segment Replication (Introduced in 2.7)

Traditional document replication forces every replica shard to re-execute the full indexing operation, causing write pressure to grow linearly with replica count. Segment replication changes this: only the primary shard performs indexing, generates Lucene segment files, and then copies those segments directly to all replicas. Replicas no longer re-index; they simply download and load segment files.

Benefits:

Indexing throughput increase : replicas avoid duplicate indexing work.

Significant CPU savings : each replica shifts from "execute indexing" to "download files".

Network bandwidth traded for compute : more network transfer, far less CPU consumption.

Read-Write Separation (Introduced in 3.0)

Three Shard Roles

Primary : Handles index writes. Unique write entry point.

Write Replica : Redundant backup. Can be promoted to Primary on failure.

Search Replica : Dedicated to search. Cannot be promoted to Primary ; assigned only to nodes with the search role, enabling hardware-level physical isolation.

Full Read-Write Separation Flow (with Remote Storage)

Primary writes segment files and transaction logs to remote storage.

Write Replica pulls segment files from remote storage.

Search Replica continuously polls remote storage and loads new segments immediately.

Core value comparison:

Write load : Traditional — Primary + Replica both process; Read-Write Separation — Only Primary processes .

Search load : Traditional — Primary + Replica both process; Read-Write Separation — Search Replica dedicated .

Resource isolation : Traditional — Mixed, mutual interference; Read-Write Separation — Hardware-level physical isolation .

Scaling : Traditional — Whole-cluster scaling; Read-Write Separation — Independent, on-demand scaling .

9.5x Performance Leap in OpenSearch 3.0 (May 2025)

Core Upgrades

Engine upgrades:

Upgraded to Apache Lucene 10 , introducing SIMD vectorization and improved I/O patterns.

Upgraded to JVM 21 , bringing modern Java features and better performance.

Architectural innovations:

Native gRPC support : HTTP/2-based multiplexing.

Read-write separation : independent configuration of indexing and search workloads.

GPU-accelerated vector indexing : index build speed improved 9.3x .

Performance Data

vs OpenSearch 1.3: Search query performance up 9.5x .

vs OpenSearch 2.19: High-impact operations average 20% improvement .

Vector search: 2.5x faster .

Range queries: 25% faster .

The gains stem mainly from Lucene 10 optimizations in vector field indexing, sparse data handling, and compression mechanisms.

Vector Search Capabilities

k-NN Vector Search

OpenSearch's core vector search is k-NN (k-Nearest Neighbors) , supporting three methods:

Approximate k-NN (ANN) : trade slight accuracy for large performance gains; default recommendation.

Exact search : brute-force comparison, suitable for small datasets.

Painless extension : distance functions as Painless script extensions, enabling complex combinations.

Engines supported: Faiss, NMSLIB, Lucene .

Hybrid Search: Keyword + Vector

OpenSearch's differentiator is hybrid search — combining keyword search (BM25) with semantic search (vector) simultaneously. BM25 scores are unbounded while k-NN returns [0,1]; normalization is required before combination. Hybrid search excels in complex queries needing both exact keyword matching and semantic similarity — BM25 captures precise matches, k-NN captures semantic similarity, and the two complement each other.

Vector Performance Evolution in 3.8 (August 2026)

Base64 Vector Encoding

A 768-dimensional float vector is ~16 KB in JSON; Base64 encoding reduces it to 4 KB, cutting network transfer by 74% . Measured benefits:

Bulk ingestion throughput up 4.16x

Median latency reduced 83%

Radial Search Optimization

On a 10-million-vector dataset:

Radial search throughput up 2.1x

Average recall improved from 0.85 to 0.97

Community and Ecosystem

Cumulative downloads : 2 billion+

Growth under Linux Foundation : 7B → 14B → 20B

Active contributors : 3,000+

Contributing organizations : 400+

Public repositories : 140+

Ecosystem components:

OpenSearch Dashboards : data visualization.

Data Prepper : data ingestion pipeline.

Piped Processing Language (PPL) : log-analysis query language.

MCP Server : seamless integration with AI agents.

OpenSearch vs Elasticsearch: Key Differences (2026)

License : OpenSearch — Apache 2.0 ; Elasticsearch — AGPLv3 / ELv2 / SSPL triple license.

Governance : OpenSearch — Linux Foundation ; Elasticsearch — Elastic N.V.

Security features : OpenSearch — All free ; Elasticsearch — Basic free, advanced paid.

Vector search : OpenSearch — Three engines (Faiss/NMSLIB/Lucene); Elasticsearch — Native support.

GPU acceleration : OpenSearch — Index acceleration 9.3x ; Elasticsearch — Limited support.

gRPC protocol : OpenSearch — Native support ; Elasticsearch — ❌.

Hybrid search : OpenSearch — Native support ; Elasticsearch — ✅.

Read-write separation : OpenSearch — 3.0 native support ; Elasticsearch — ❌.

MCP protocol : OpenSearch — 3.0 native support ; Elasticsearch — ❌.

Cloud service : OpenSearch — Amazon OpenSearch Service, etc.; Elasticsearch — Elastic Cloud.

Three core differentiators in 2026:

OpenSearch delivers "full-stack free" — security, alerting, ML, SQL all built-in and free.

OpenSearch delivers "architectural certainty" — Apache 2.0 license will never change.

OpenSearch delivers "governance neutrality" — hosted by Linux Foundation, no single vendor control.

Recommended Use Cases

License-sensitive enterprises : ✅ OpenSearch — Apache 2.0 fully open, no surprise changes.

Log analytics / observability : ✅ OpenSearch — Full-stack free, powerful PPL for log analysis.

SIEM / security analytics : ✅ OpenSearch — Security analytics, alerting, anomaly detection all free.

RAG / vector retrieval : ✅ OpenSearch — Hybrid search + vector retrieval, GigaOm leader.

AWS cloud-native apps : ✅ OpenSearch — Native integration with Amazon OpenSearch Service.

Search relevance is core IP : ⚠️ Elasticsearch — Faster search innovation iteration.

Deeply invested in Kibana ecosystem : ⚠️ Elasticsearch — OpenSearch Dashboards has learning curve.

Existing ES commercial subscription : ⚠️ Elasticsearch — Continue with current investment.

Conclusion

Why are more people choosing OpenSearch? The answer is straightforward: it provides at the architectural level what Elasticsearch cannot — certainty and freedom .

License certainty: Apache 2.0 forever.

Governance neutrality: Linux Foundation stewardship.

Advanced architecture: read-write separation, segment replication, gRPC, GPU-accelerated vector indexing — capabilities unique to the OpenSearch 3.0 era.

OpenSearch is no longer the 2021 "Elasticsearch fork." Version 3.0 represents an architectural leap : Lucene 10 + JVM 21 + gRPC + read-write separation + GPU acceleration — these are not "catching up" but "redefining."

Technology selection has no absolute right or wrong. Clarify what you value most — license freedom, architectural certainty, or feature velocity — and the choice becomes clear.

Open source references:

OpenSearch website : https://opensearch.org

GitHub : https://github.com/opensearch-project/OpenSearch

Official documentation : https://docs.opensearch.org