Elasticsearch vs OpenSearch

Quick verdict: Elasticsearch vs OpenSearch

Choose Elasticsearch if you need the most mature vector search implementation, run on Google Cloud or Azure, or already have deep Elastic Stack expertise — AGPLv3 now covers most open-source licensing requirements too.

Choose OpenSearch if you run on AWS and want native managed hosting, prefer Apache 2.0's simpler terms, or want vendor-neutral Linux Foundation governance over a single company's roadmap.

The "SSPL forces you to OpenSearch" argument is weaker than it used to be — Elasticsearch has offered a genuine open-source license (AGPLv3) since September 2024.

When to choose Elasticsearch vs OpenSearch

That's the generic picture. Vector search maturity and where your infrastructure already lives are what usually tip it. ↓

Elasticsearch vs OpenSearch: what actually changed in 2026

The licensing argument that originally drove this whole comparison has substantially resolved. In September 2024, Elastic added AGPLv3, an OSI-approved open-source license, as a third option alongside SSPL and the Elastic License v2. Teams that switched to OpenSearch specifically because Elasticsearch "wasn't open source" can now use Elasticsearch under AGPL instead. That's not a perfect substitute for Apache 2.0, AGPL carries network-copyleft obligations Apache 2.0 doesn't, but "Elasticsearch is closed source" stopped being an accurate blanket claim well before this was last reviewed.

The same month, OpenSearch's governance changed too: AWS handed stewardship to the Linux Foundation's newly formed OpenSearch Software Foundation. That's a real shift from "AWS's fork" to community-governed infrastructure, and it directly addresses the durability concern some teams had about depending on a single vendor's fork. The Foundation followed up in April 2026 with a formal long-term support program, closing a gap that used to favor Elasticsearch's more established release discipline.

None of this erases the projects' real remaining differences. Elasticsearch's vector search tooling is still ahead, and Elastic Cloud's multi-cloud managed offering remains broader than Amazon OpenSearch Service's AWS-only first-class support. But the decision is now genuinely about technical fit and vendor relationship, not a forced choice between "open source" and "not open source."

If a comparison you're reading treats SSPL as Elasticsearch's only license or OpenSearch as simply "AWS's Elasticsearch fork," it predates these 2024 changes.

Elasticsearch vs OpenSearch: serverless pricing in 2026

Both vendors now default new customers to serverless, and the pricing models are structured differently enough that a head-to-head instance comparison no longer tells the whole story. Elasticsearch Serverless bills $0.09 per VCU-hour for search, $0.14 per VCU-hour for ingest, and $0.047/GB/month for storage, with no minimum footprint and no per-endpoint fee as of March 2026. A small workload can genuinely cost a few dollars a month.

Amazon OpenSearch Serverless charges $0.24 per OCU-hour, and production collections require a 2-OCU minimum for indexing plus 2 OCUs for search, which puts a real floor of roughly $350/month on any workload you'd actually run in production, even at near-zero traffic. AWS's OpenSearch Serverless NextGen tier, generally available since May 2026, adds scale-to-zero and decoupled compute/storage billing aimed squarely at closing that gap, but it is opt-in and not yet the default for existing collections.

For spiky or low-traffic workloads, Elasticsearch Serverless is meaningfully cheaper to start. For large, steady-state production clusters already inside AWS, OpenSearch's per-OCU pricing and existing Reserved Instance discounts on the managed (non-serverless) service can still come out ahead, especially once you factor in AWS's own committed-spend credits.

Model your actual traffic pattern before comparing sticker prices. A workload that's spiky or low-volume favors Elasticsearch's pay-per-use floor; a large steady-state cluster on AWS may still favor OpenSearch's managed pricing.

Elasticsearch vs OpenSearch: vector search and RAG workloads

Vector search is where the two projects have diverged the most since the 2021 fork, and it's worth correcting a common assumption: the two are not performance-equivalent just because both wrap Lucene. In Elastic's own 2026 benchmark on a 20-million-document filtered vector search test, Elasticsearch (using its BBQ scalar quantization) reported roughly 90ms average latency versus roughly 687ms for OpenSearch on comparable hardware — Elastic frames this as up to 12x faster, with an even wider gap on exact kNN. Treat that number as a vendor benchmark, not an independent one, but the underlying reason is real: tighter Lucene integration lets Elasticsearch push quantization further without a separate plugin layer.

OpenSearch is not standing still. Its k-NN plugin supports FAISS, NMSLIB, and Lucene engines, OpenSearch 3.5 (February 2026) shipped a 58% vector throughput improvement via SIMD-accelerated FP16 operations, and 3.6 (April 2026) added 1-bit scalar quantization and an Agent-v2 framework for building RAG pipelines natively. For moderate-scale vector workloads, the gap is far smaller than the headline benchmark suggests.

If you're building a large-scale RAG pipeline where p99 vector query latency directly affects user-facing response time, Elasticsearch's quantization advantage is worth validating against your own data. If vector search is one feature among many in a broader logging or observability platform, OpenSearch's native k-NN plugin is good enough for most teams and comes without a license change to plan around.

Don't take either vendor's benchmark at face value — run your own test on your actual document set and filter patterns before committing a production RAG pipeline to either engine.

Common questions about Elasticsearch vs OpenSearch