OpenSearch 3.0: Segment Replication, Read-Write Separation, and 9.5x Performance Boost
OpenSearch has evolved from an Elasticsearch fork into a Linux Foundation-governed Apache 2.0 platform with architectural innovations like segment replication and read-write separation, delivering 9.5x search performance gains in version 3.0, plus native GPU-accelerated vector indexing, hybrid search, and a growing ecosystem, making it a compelling alternative for license-sensitive, observability, and AI-driven search workloads.
History and Governance
OpenSearch originated in January 2021 when Elastic changed Elasticsearch and Kibana licenses from Apache 2.0 to SSPL + Elastic License v2. SSPL requires that if the software is offered as a service, the entire management stack source code must be open-sourced. AWS responded by forking Elasticsearch 7.10.2 (the last Apache 2.0 version) and naming it OpenSearch. OpenSearch 1.0 launched in July 2021.
A pivotal shift occurred 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
OpenSearch Core comprises five concepts: Cluster , Node , Index , Shard , and Document . Node types define responsibilities:
Data nodes : store index data, handle ingestion, search, and aggregation.
Master nodes : manage cluster-level operations.
Coordinating nodes : route client requests to data nodes.
Inverted Index
Search is built on Apache Lucene 's inverted index , mapping terms to document lists for instant lookup. The logic is "keyword → document list" rather than "document → keywords".
Segment Replication (OpenSearch 2.7)
Traditional document replication forces every replica shard to re-execute the full indexing pipeline, causing write pressure to scale linearly with replica count. Segment replication changes this: only the primary shard indexes documents and generates Lucene segment files, which are then copied to all replicas. Replicas simply download and load segments without re-indexing.
Benefits:
Indexing throughput increase : replicas no longer repeat indexing work.
CPU savings : each replica shifts from "execute indexing" to "download file".
Network bandwidth for compute : more network transfer, far less CPU consumption.
Read-Write Separation (OpenSearch 3.0)
Three Shard Roles
OpenSearch 3.0 introduces 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 become Primary; assigned only to nodes with search role, enabling hardware-level isolation.
Full Read-Write Separation Flow
With remote storage enabled:
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.
Comparison with traditional mode:
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 scales together; Read-Write Separation — Independent, on-demand scaling .
Performance Leap in OpenSearch 3.0 (May 2025)
Core Upgrades
Engine upgrade : Apache Lucene 10 (SIMD vectorization, improved I/O) and JVM 21 (modern Java features, better performance).
Architecture innovations : native gRPC (HTTP/2 multiplexing), read-write separation, GPU-accelerated vector indexing (9.3x faster index build).
Benchmark Results
vs OpenSearch 1.3: Search query performance up 9.5x .
vs OpenSearch 2.19: High-impact operations average up 20% .
Vector search: Performance up 2.5x .
Range queries: Performance up 25% .
Gains stem from Lucene 10 optimizations in vector field indexing, sparse data handling, and compression.
Vector Search Capabilities
k-NN Search
OpenSearch supports three methods:
Approximate k-NN (ANN) : trade slight accuracy for large speed gains; default recommendation.
Exact search : brute-force comparison; suitable for small datasets.
Painless extension : distance functions as Painless script extensions for complex combinations.
Engines: Faiss , NMSLIB , Lucene .
Hybrid Search
OpenSearch's differentiator is hybrid search — combining keyword search (BM25) with semantic search (vectors) simultaneously. BM25 scores are unbounded; k-NN returns [0,1]; normalization is required before combination.
Hybrid search excels in complex queries needing both exact keyword matches and semantic similarity — BM25 captures precise terms, k-NN captures semantic meaning.
Vector Performance Evolution (OpenSearch 3.8, August 2026)
Base64 Vector Encoding
A 768-dimension float vector occupies ~16 KB in JSON; Base64 encoding reduces it to 4 KB, cutting network transfer by 74% .
Measured gains:
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 : visualization.
Data Prepper : ingestion pipeline.
Piped Processing Language (PPL) : log-analysis query language.
MCP Server : seamless AI agent integration.
OpenSearch vs Elasticsearch Comparison
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 engines : OpenSearch — Three (Faiss/NMSLIB/Lucene); Elasticsearch — Native support.
GPU acceleration : OpenSearch — Index speedup 9.3x ; Elasticsearch — Limited support.
gRPC protocol : OpenSearch — Native support ; Elasticsearch — ❌.
Hybrid search : Both ✅ Native.
Read-write separation : OpenSearch — 3.0 native ; Elasticsearch — ❌.
MCP protocol : OpenSearch — 3.0 native ; Elasticsearch — ❌.
Cloud service : OpenSearch — Amazon OpenSearch Service, etc.; Elasticsearch — Elastic Cloud.
Three core differentiators in 2026:
Full-stack free — security, alerting, ML, SQL all built-in and free.
License certainty — Apache 2.0 will never change.
Governance neutrality — Linux Foundation hosting prevents vendor capture.
Recommended Use Cases
License-sensitive enterprises → ✅ OpenSearch — Apache 2.0 fully open, no surprise changes.
Log analysis / observability → ✅ OpenSearch — Full-stack free, powerful PPL for logs.
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 — Amazon OpenSearch Service native integration.
Search relevance is core IP → ⚠️ Elasticsearch — Faster search innovation iteration.
Deep Kibana ecosystem lock-in → ⚠️ Elasticsearch — OpenSearch Dashboards has learning curve.
Existing ES commercial subscription → ⚠️ Elasticsearch — Continue with current investment.
Conclusion
OpenSearch delivers what Elasticsearch cannot: certainty and freedom . License certainty (Apache 2.0 forever), governance neutrality (Linux Foundation), and architectural advances — read-write separation, segment replication, gRPC, GPU-accelerated vector indexing — are unique to the OpenSearch 3.0 era. The 3.0 release represents an architectural leap , not mere catch-up: Lucene 10 + JVM 21 + gRPC + read-write separation + GPU acceleration redefine the platform. Technology choices have no absolute right or wrong; clarify what matters most — license freedom, architectural predictability, or feature velocity — and the answer becomes clear.
Open source links:
OpenSearch website : https://opensearch.org
GitHub : https://github.com/opensearch-project/OpenSearch
Official documentation : https://docs.opensearch.org
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
IT Services Circle
Delivering cutting-edge internet insights and practical learning resources. We're a passionate and principled IT media platform.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
