Why OpenSearch Is Gaining Massive Adoption: Architecture, Features, and Performance

Introduction

The author recounts a conversation with a colleague who wondered whether OpenSearch could match Elasticsearch’s capabilities, highlighting a common misconception that OpenSearch is merely an AWS fork.

1. How OpenSearch Originated

In January 2021 Elastic changed the Elasticsearch and Kibana licenses to SSPL + Elastic License v2, requiring SaaS providers to open‑source their entire stack. AWS responded by forking the last Apache‑2.0 version (7.10.2) and releasing OpenSearch 1.0 in July 2021.

The decisive shift occurred in September 2024 when AWS transferred governance to the Linux Foundation, creating the OpenSearch Software Foundation with founding members such as AWS, SAP, Uber, Aiven, and Canonical. From that point OpenSearch and Elasticsearch diverged permanently.

In August 2024 Elastic added AGPLv3 as a third license option, introducing the “network‑use‑is‑distribution” clause.

2. Architecture Overview

OpenSearch Core is built on five core concepts: Cluster, Node, Index, Shard, and Document.

2.1 Node Types

Data node : stores index data and handles ingestion, search, and aggregation.

Master node : performs cluster‑level management operations.

Coordinating node : receives client requests and routes them to data nodes.

2.2 Inverted Index

Search is powered by Apache Lucene. Lucene’s fundamental data structure is the inverted index, which maps each term to the list of documents containing that term. When a user searches for “OpenSearch”, the system looks up the term in the inverted index and instantly retrieves all matching documents.

3. Segment Replication

OpenSearch 2.7 introduced Segment Replication, replacing the traditional document‑level replication where each replica re‑executes the full indexing operation. With Segment Replication only the primary shard performs indexing, generates Lucene segment files, and copies those files to replicas. This eliminates duplicate indexing work, reduces CPU usage, and trades network bandwidth for compute.

Indexing throughput increases because replicas no longer re‑index.

CPU consumption drops dramatically as replicas only download and load segment files.

Network traffic grows, but overall resource efficiency improves.

4. Read/Write Separation

OpenSearch 3.0 added native read/write separation.

4.1 Shard Roles

Primary : sole write entry point, handles indexing writes.

Write Replica : redundant backup; can be promoted to Primary on failure.

Search Replica : dedicated to search only; cannot become Primary and must be placed on nodes with the search role, achieving hardware‑level isolation.

4.2 Full Separation Flow

Primary writes segment files and transaction logs to remote storage.

Write Replica pulls segment files from remote storage.

Search Replica continuously polls remote storage, loads new segments as soon as they appear.

5. Performance Leap (9.5×)

OpenSearch 3.0 (May 2025) delivered the first major release in three years, featuring:

Upgrade to Apache Lucene 10 with SIMD vectorization and improved I/O.

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

Native gRPC support (HTTP/2 multiplexing).

Read/write separation.

GPU‑accelerated vector indexing (9.3× faster).

5.2 Benchmark Results

Compared with OpenSearch 1.3, search query performance improves by 9.5×.

Compared with OpenSearch 2.19, high‑impact operations improve by 20% on average.

Vector search speed increases by 2.5×.

Range query speed increases by 25%.

These gains stem mainly from Lucene 10’s optimizations for vector fields, sparse data handling, and compression.

6. Vector Search

OpenSearch’s core vector capability is k‑Nearest Neighbors (k‑NN), offered in three implementations: Faiss, NMSLIB, and Lucene.

Approximate k‑NN (ANN) : sacrifices a small amount of accuracy for large performance gains; default recommendation.

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

Painless extension : distance functions can be expressed as Painless scripts for complex combinations.

Hybrid Search combines BM25 keyword matching with vector similarity, allowing both precise term matches and semantic relevance. BM25 scores are unbounded, while k‑NN scores lie in [0, 1]; they must be normalized before fusion.

7. Vector Performance Evolution

Base64 encoding reduces a 768‑dimensional float vector from ~16 KB to ~4 KB in JSON, cutting network transfer by 74%.

Batch ingestion throughput improves by 4.16×.

Median latency drops by 83%.

On a 10 million‑vector dataset, radial search throughput rises 2.1× and average recall climbs from 0.85 to 0.97.

8. Community Ecosystem

Cumulative downloads exceed 20 billion.

Growth after Linux‑Foundation governance: 7 B → 14 B → 20 B downloads.

Active contributors > 3,000 and > 400 contributing organizations.

Public repositories > 140.

The ecosystem includes:

OpenSearch Dashboards – data visualization.

Data Prepper – data ingestion pipeline.

Piped Processing Language (PPL) – log‑analysis query language.

MCP server – seamless AI‑Agent integration.

9. OpenSearch vs. Elasticsearch Differences

License : OpenSearch – Apache 2.0 (permanent); Elasticsearch – AGPLv3 / ELv2 / SSPL (dual).

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

Security features : OpenSearch – fully free; Elasticsearch – basic free, advanced paid.

Vector search : OpenSearch – three engines (Faiss, NMSLIB, Lucene); Elasticsearch – native support.

GPU acceleration : OpenSearch – 9.3× index speed; Elasticsearch – limited.

gRPC : OpenSearch – native; Elasticsearch – not supported.

Hybrid search : both support.

Read/write separation : OpenSearch – native in 3.0; Elasticsearch – not.

MCP protocol : OpenSearch – native in 3.0; Elasticsearch – not.

Cloud services : OpenSearch – Amazon OpenSearch Service; Elasticsearch – Elastic Cloud.

10. Recommended Use Cases

Enterprises sensitive to open‑source licensing – choose OpenSearch for its immutable Apache 2.0 license.

Log analysis / observability – OpenSearch offers a free full‑stack (PPL, alerts, ML).

SIEM / security analytics – all features are free.

RAG / vector retrieval – hybrid search + vector search, recognized as a GigaOm leader.

AWS cloud‑native applications – native integration with Amazon OpenSearch Service.

When search relevance is the core competitive edge – Elasticsearch may iterate faster.

Projects deeply tied to the Kibana ecosystem – Elasticsearch may have lower learning curve; OpenSearch Dashboards requires onboarding.

Existing Elasticsearch commercial subscriptions – staying with Elasticsearch is reasonable.

11. Conclusion

The core answer to “Why are more people using OpenSearch?” is that it provides architectural certainty and freedom that Elasticsearch cannot: a permanent Apache 2.0 license, governance by the neutral Linux Foundation, and advanced features such as segment replication, read/write separation, gRPC, and GPU‑accelerated vector indexing introduced in the 3.0 era.

These capabilities, combined with rapid performance gains (e.g., 9.5× query speed) and a thriving community, make OpenSearch a compelling choice for modern AI‑driven search workloads.