Elasticsearch Vector vs OpenSearch vs Typesense (2026): The Honest Search Comparison

The Elastic vs OpenSearch split began in January 2021, when Elastic re-licensed Elasticsearch and Kibana from Apache 2 to the SSPL (Server Side Public License) and the Elastic License 2.0, citing concerns about large cloud providers (notably AWS) running Elasticsearch as a managed service without contributing back. AWS responded by forking Elasticsearch 7.10.2 under the Apache 2 license to create OpenSearch, committing to keep it fully open. This licensing story directly shapes your vendor risk today.

For self-hosted Elasticsearch, the practical split is: core full-text search, aggregations, basic kNN vector search, and BM25 are under the Apache 2 license (or the Elastic Source Available License, which allows most non-SaaS commercial use). But ELSER (the sparse learned encoder that powers semantic search without external embeddings), semantic_text automatic embedding, ML nodes, and the full AI Search stack are under the Elastic License 2.0 — which prohibits providing the software to third parties as a service. If you are building a search product and reselling it to customers, Elastic License creates legal friction. If you are using Elasticsearch internally, Elastic License is a non-issue for most organizations.

OpenSearch carries no ML feature gating. Every vector search feature, the neural search pipeline, sparse neural retrieval, hybrid search with normalization processors — all Apache 2. No per-feature tier unlocking, no license check at ML node startup. If open licensing is a hard requirement for your architecture (government procurement, open-source product, concerns about long-term vendor lock-in), OpenSearch or Typesense are your options.

Typesense uses Apache 2 for the server binary; some client libraries moved to the Business Source License (BSL 1.1) in late 2024, which converts to Apache 2 after four years. BSL restricts using the client library itself to provide a competing search-as-a-service product, but does not restrict building applications on top of Typesense. For almost all application teams, Typesense licensing is clean.

The practical bottom line: if you are an internal enterprise team self-hosting search, Elastic License is typically not a barrier and you can use ELSER freely. If you are building a product that embeds search as a feature and sells it to customers, the Apache 2 stack (OpenSearch or Typesense) removes legal ambiguity. If you are a startup on AWS, OpenSearch + managed service is the path of least friction — you avoid the Elastic License complexity and integrate natively with SageMaker and Bedrock for embeddings.

One more licensing angle: Elastic has also changed the licensing of Elasticsearch multiple times since 2018 (first to a dual license in 2018, then SSPL in 2021, then Elastic License 2.0). Organizations burned by the 2021 change reason that the license could change again. OpenSearch, governed by AWS with Apache 2 as the stated permanent license, and Typesense, a small focused company with a clean server license, both carry lower re-licensing risk.

ELSER (Elastic Learned Sparse Encoder) is Elastic's proprietary sparse text encoding model, available under the Elastic License on Elasticsearch 8.x and Elastic Cloud. It is the most architecturally distinctive feature in the Elasticsearch vector stack and deserves a careful explanation, because it solves a specific problem that dense vector kNN search does not.

Standard dense vector search requires: (1) run your text through an embedding model (OpenAI, Cohere, Voyage, or a self-hosted model) to produce a float-vector, (2) store the vector in a dense_vector field, (3) at query time, embed the query with the same model and run an approximate-nearest-neighbor (ANN) search. This is the standard RAG pipeline. The dependency on an external embedding model is a real operational burden — you need an API key, you pay per token, the embedding call adds latency, and if the API is down, your search degrades.

ELSER produces a sparse vector instead of a dense vector. Sparse vectors represent text as a weighted bag of tokens from an expanded vocabulary (150,000+ tokens), where only a few hundred weights are non-zero. ELSER learns which expanded terms are semantically related to each document term — effectively performing query expansion and semantic enrichment at index time, stored as a sparse_vector field inside Elasticsearch. At query time, ELSER runs the same sparse expansion on the query and computes a dot-product similarity. No external API call. No embedding service dependency. The sparse model runs locally on an ML node in your Elasticsearch cluster.

Why sparse vectors matter for hybrid search: ELSER's sparse retrieval and BM25 lexical retrieval operate in compatible term-space, making hybrid fusion (RRF or linear combination) more semantically coherent than hybrid fusion of dense vectors and BM25. The built-in RRF (Reciprocal Rank Fusion) implementation in Elasticsearch 8.x combines ELSER sparse scores and BM25 lexical scores with a single query, no external orchestration required. This is the most seamless hybrid search story in the ecosystem as of June 2026.

The cost of ELSER: it runs on ML nodes, which in Elastic Cloud are billed separately from data nodes. An ML node for ELSER inference typically adds $0.10-0.30/hour to your Elastic Cloud bill depending on model size. At scale (millions of ELSER inference calls per day), you size the ML node tier accordingly. For Elasticsearch self-hosted, ELSER requires the Elastic License — you can download and use it for free in development, but production use requires a subscription (starting at $95/month on Elastic Cloud, or an enterprise license agreement for self-hosted at scale).

ELSER v2 (the current generation as of Elasticsearch 8.11+) outperforms ELSER v1 on BEIR benchmarks and supports a 512-token input window. For most semantic search use cases without long documents, ELSER v2 delivers comparable retrieval quality to a dense vector pipeline using text-embedding-3-small or voyage-3-lite — while eliminating the external embedding API dependency entirely. That is a real architectural simplification worth the Elastic License cost for many teams.

OpenSearch 2.x replicates most of Elasticsearch's semantic search capabilities under the Apache 2 license, but with different architecture and a tighter AWS integration story. The neural search pipeline is the core mechanism: you define a model (hosted on SageMaker, accessed via Amazon Bedrock, or a community model from the OpenSearch ML Commons registry) and attach it to an ingest pipeline. Documents flowing through the pipeline are auto-embedded at index time — no external embedding call at application layer, analogous to Elasticsearch's semantic_text field type.

OpenSearch 2.11+ added neural sparse retrieval, which is comparable to ELSER in concept — a learned sparse encoder model maps text to weighted token expansions for efficient approximate sparse vector search. The key difference: the default neural sparse models in OpenSearch are community-contributed or AWS-hosted, not proprietary. As of June 2026, neural sparse retrieval in OpenSearch is maturing but lags ELSER v2 on BEIR benchmarks. For most teams adopting OpenSearch for its AWS-native licensing and integration story, dense vector kNN via FAISS is the primary semantic search mechanism, not neural sparse.

Hybrid search in OpenSearch uses a normalization processor in the search pipeline, which can apply arithmetic mean, geometric mean, harmonic mean, or min-max normalization to combine scores from different retrieval sub-queries. RRF is also available (OpenSearch 2.11+). The configuration is more explicit than Elasticsearch's built-in RRF — you wire up the hybrid pipeline manually — but the end capability is equivalent.

FAISS integration is a genuine advantage of OpenSearch for very large scale or GPU-accelerated scenarios. While Elasticsearch uses pure HNSW (no GPU support), OpenSearch's kNN plugin can fall back to FAISS IVF (inverted file index) for extremely large corpora where pure HNSW memory requirements become prohibitive. FAISS also supports GPU acceleration for large-scale batch re-indexing, though this requires managing GPU infrastructure yourself.

The rerank processor (OpenSearch 2.12+) integrates with Bedrock rerank models and SageMaker-hosted cross-encoder models, enabling two-stage retrieval without routing queries through an external API in application code. For AWS-native stacks, this is genuinely more integrated than Elasticsearch + Cohere rerank, where the rerank call goes to Cohere's API outside your AWS VPC.

Practical note on version skew: OpenSearch forked from Elasticsearch 7.10.2 in 2021 and has advanced independently. Some Elasticsearch query DSL syntax, analyzer behavior, and aggregation semantics that changed between ES 7.10 and ES 8.x are not present in OpenSearch 2.x, or behave differently. If you are migrating a production Elasticsearch 8.x system to OpenSearch 2.x, audit your query DSL carefully — this is not a drop-in replacement without testing.

Amazon OpenSearch Serverless is AWS's fully managed, auto-scaling OpenSearch service with per-use pricing — you pay for OpenSearch Compute Units (OCUs) consumed by indexing and search operations, rather than provisioning instances. The appeal is obvious: no cluster sizing, no shard rebalancing, no JVM tuning. The pricing trap is less obvious: the minimum viable deployment is expensive.

As of June 2026, OpenSearch Serverless pricing in us-east-1 is: $0.24 per OCU-hour for indexing OCUs, and $0.24 per OCU-hour for search OCUs. AWS requires a minimum of 2 OCUs per collection (not per account — per collection), with at minimum 1 indexing OCU and 1 search OCU. Each collection runs 24 hours a day whether you query it or not. Math: 2 OCUs × $0.24 × 24 hours × 30 days = $345.60/month minimum, per collection. Add object storage at $0.024/GB-month for the index data itself.

For a lightly loaded collection that gets a few hundred queries per day, the serverless floor pricing means you are paying $350/month for a workload that a $50/month EC2 instance with self-managed OpenSearch could handle. Serverless is cost-effective only when workloads are highly bursty (zero traffic most of the time, high bursts when active), when you genuinely cannot afford operational overhead, or when OCU consumption under load justifies the pricing model.

Amazon OpenSearch Service (the provisioned, non-serverless tier) is priced differently and is usually more cost-effective for predictable workloads. A t3.small.search instance (2 vCPU, 2 GB RAM) runs approximately $0.10/hour = $73/month in us-east-1. A c6g.large.search (2 vCPU, 4 GB RAM) runs approximately $0.19/hour = $138/month. Production kNN workloads need memory-optimized instances — r6g.xlarge.search (4 vCPU, 32 GB RAM) at $0.756/hour = $544/month per data node. With a 3-node production cluster for HA, that is $1,632/month.

Cross-platform cost for a 50M-document vector search corpus (1024-dim vectors, approximately 200 GB of vector data): **OpenSearch Serverless** — storage at $0.024/GB × 200 GB = $4.80/month storage plus the 2-OCU minimum = ~$355/month floor. OCU burst costs under moderate query load likely add $50-200/month. **Elasticsearch Cloud I/O-optimized** — a modest 3-node cluster appropriate for 200 GB data + HNSW index overhead runs approximately $400-600/month. ELSER ML nodes add $200-400/month. **Typesense Cloud** — the RAM4 tier (12 GB RAM, 2 vCPU) at $0.175/hour = $127/month handles 200 GB data only with aggressive on-disk configuration; 200 GB in-memory requires the RAM32 tier at $0.699/hour = $510/month. For truly large corpora, verify current Typesense Cloud pricing and RAM tier availability at typesense.org/pricing before procurement.

The cost story for a 50M-doc corpus: all three platforms are in the $350-800/month range for managed cloud deployments, depending on configuration. Self-hosted on EC2 or bare metal shifts the cost to infrastructure + engineering time, typically lower for teams with existing DevOps capability. Typesense self-hosted is the lowest-cost option if you have enough RAM ($0 license, simple ops, lower infra requirements than Elasticsearch/OpenSearch JVM stacks).

Typesense is written in C++, designed for in-memory operation, and optimized for one specific use case: real-time search-as-a-feature in applications. Think e-commerce product search, documentation search, knowledge base search, SaaS in-app search. It is not trying to be a log aggregation platform, an analytics engine, or a distributed data warehouse. That focus produces a genuinely different developer experience.

Setup: a single Docker container, a single API key, REST API that mirrors Elasticsearch in spirit but is dramatically simpler in practice. No JVM heap configuration, no shard sizing decisions, no cluster topology planning for a single-node instance. A developer can run `docker run -p 8108:8108 typesense/typesense:latest --data-dir=/data --api-key=xyz` and have a functional search engine in 60 seconds. For teams where search is a feature (not the core product), this operational simplicity is the defining advantage.

Typesense's full-text search quality is excellent for the use cases it targets. Typo tolerance is built-in and highly tunable (number of typos allowed per word, typo weight in ranking, prefix search, infix search). Faceting, sorting, and ranking rules are first-class. The developer experience for configuring relevance — via an intuitive JSON schema for collection definitions and query parameters — is genuinely superior to Elasticsearch's function_score complexity.

Vector search (added in Typesense v0.25, 2023) supports HNSW-backed ANN search with float32 vectors up to 1,536 dimensions. Hybrid search (keyword + vector) is available as alpha/beta functionality. The limitation: you must generate vectors externally and pass them at ingest. Typesense does not run a model inference server, does not have an ELSER equivalent, and does not connect to SageMaker or Bedrock. For teams already generating embeddings in their application pipeline (calling OpenAI or Cohere), this is no inconvenience. For teams wanting an all-in-one semantic search stack with auto-embedding at ingest, Typesense requires more application-layer glue.

Where Typesense hits its ceiling: (1) large analytical write volumes — Typesense is optimized for read-heavy search workloads, not write-heavy ingestion pipelines. Log-scale write throughput (millions of documents per hour) will overwhelm it. (2) Corpus size — because Typesense keeps working data in RAM for performance, a 100M-document dense vector corpus (1024 dims) requires roughly 400+ GB of RAM. At that scale, managed Typesense Cloud costs exceed Elasticsearch or OpenSearch. (3) Complex aggregations — Elasticsearch-style nested aggregations, percentile aggregations, time-series rollups are not in Typesense's scope. (4) Multi-tenancy isolation — Typesense has alias and multi-collection support but lacks Elasticsearch's index-level security, role-based field-level access controls, and audit logging that enterprises require.

The honest conclusion on Typesense: for product search, docs search, in-app search on corpora under 10M documents where the team values simplicity and does not need ML inference built-in, Typesense is the best developer experience in this comparison. For corpora over 50M documents, for semantic search with auto-embedding, for log analytics, or for enterprise security requirements, Typesense is not the right tool. It knows what it is.

Hybrid search — combining keyword (BM25) retrieval and dense or sparse vector retrieval into a single ranked result set — is now table stakes for production semantic search. The implementations differ meaningfully across these three platforms.

Elasticsearch 8.x ships the most complete hybrid search story. A single query can combine: (1) BM25 lexical matching on text fields, (2) kNN dense vector ANN search on dense_vector fields, (3) ELSER sparse vector retrieval on sparse_vector fields. RRF (Reciprocal Rank Fusion) is built into the query DSL — you specify the sub-queries and RRF blends the rank lists into a unified score. The key advantage: ELSER sparse retrieval and BM25 are both term-based, so their scores are semantically commensurable. RRF fusion of three signals (BM25 + dense kNN + ELSER sparse) often outperforms any single signal in out-of-distribution queries — the ELSER sparse component handles vocabulary mismatch that BM25 misses, the dense kNN component handles semantic paraphrasing that BM25 and sparse both miss.

OpenSearch 2.x achieves comparable hybrid search through a more explicit pipeline configuration. You define a search pipeline with a normalization processor that combines the score distributions from a BM25 sub-query and a neural kNN sub-query, using configurable combination methods (arithmetic mean, geometric mean, harmonic mean, L2 normalization + min-max, or RRF). The result quality is competitive with Elasticsearch when properly tuned. The operational difference is configuration verbosity — where Elasticsearch handles RRF fusion in the query DSL, OpenSearch requires wiring up the pipeline separately from the query.

Typesense's hybrid search is available but significantly simpler and more limited. You can issue a query that runs both full-text and vector search and merges results. As of June 2026, the fusion logic and tuning options are less sophisticated than either Elasticsearch or OpenSearch — there is no RRF implementation, no multi-signal fusion (BM25 + sparse + dense simultaneously), and no normalization processor equivalent. For product/docs search use cases, Typesense's hybrid mode is usually sufficient. For enterprise semantic search where retrieval quality is mission-critical, the limited hybrid fusion is a real gap.

For teams building their first semantic search feature with a tight deadline: Elasticsearch with ELSER + RRF hybrid is the fastest path to a high-quality hybrid search system without building embedding infrastructure, assuming you can afford the Elastic License. For teams on AWS wanting full Apache 2 and AWS-native integration: OpenSearch neural search pipeline + normalization processor is the right choice — more wiring but equivalent end capability. For teams with small-to-mid corpora where hybrid precision matters less than operational simplicity: Typesense hybrid is sufficient, and the time saved on ops is better spent elsewhere.

A note on int8 quantization: Elasticsearch supports int8 quantization on dense_vector fields, which reduces storage by approximately 4x with typically less than 1-2% quality loss on retrieval benchmarks. At a 50M-document corpus with 1024-dim vectors (200 GB float32), int8 quantization reduces vector storage to approximately 50 GB. OpenSearch supports similar byte-quantization (OpenSearch 2.13+). Typesense does not support quantization as of June 2026. For large corpora, quantization support is a meaningful storage cost lever — verify availability with the vector DB cost calculator.

Elasticsearch is the right choice when you need the most mature ML-augmented search stack available and are willing to accept the Elastic License for the ML features. The ELSER + semantic_text + RRF hybrid search combination is the deepest out-of-the-box semantic search story in this comparison as of June 2026.

Use Elasticsearch when: you have an existing Elasticsearch deployment and upgrading to 8.x + ELSER is lower friction than a platform migration. When your corpus is complex and requires the full BM25 + dense kNN + ELSER sparse three-way hybrid. When you need the richest relevance tuning controls (script_score, function_score, learning to rank). When you need Elasticsearch's mature security model (field-level security, index-level RBAC, audit logging) for enterprise compliance.

Elasticsearch also wins for log and time-series analytics workloads. Kibana + Elastic Stack (Logstash / Beats / Elastic APM) is the most complete observability platform in this set. If your team already runs the ELK stack for APM/logging and wants to add semantic search, ELSER is the zero-new-vendor path.

Watch out for: Elastic Cloud pricing scaling steeply with ML node requirements. ELSER inference adds meaningful latency for high-QPS (queries per second) search APIs — at >500 QPS, size ML nodes carefully. The Elastic License restrictions if you ever want to build a search-as-a-service product. And the operational complexity of Elasticsearch — JVM heap sizing, shard strategy, and mapping management are not trivial.

Self-hosted Elasticsearch on Kubernetes or bare metal is viable for teams with the infrastructure expertise. The Elastic operator for Kubernetes (ECK, Elastic Cloud on Kubernetes) is mature and well-documented. Self-hosting unlocks the full Elastic License feature set without the cloud pricing — but you own the operational burden entirely.

Bottom line: Elasticsearch is the enterprise-grade choice with the most sophisticated ML search features. It earns that position with real capability. The price tag — in licensing complexity, Elastic Cloud costs, and operational overhead — is real and should be budgeted honestly.

OpenSearch wins when AWS is your primary cloud, when Apache 2 licensing is a hard requirement, or when you want a managed search service that integrates with Bedrock and SageMaker without licensing friction.

Use OpenSearch when: your stack is AWS-native and you want IAM-based access control, VPC-private endpoints, CloudWatch integration, and no cross-cloud API calls for inference. When your org has compliance or procurement rules that require Apache 2 licensing throughout the stack. When you need the AWS-managed SLA for search availability without running the infrastructure yourself.

OpenSearch Serverless specifically wins for workloads that are genuinely bursty — a nightly batch job that runs heavy indexing for 2 hours then sits idle for 22 hours, or a product that has viral traffic spikes but mostly quiet baseline. In those scenarios, the OCU-based pricing can come out cheaper than provisioned instances, and the zero-ops scaling is the real value.

AWS native embedding: the neural search pipeline with Amazon Bedrock Titan Embeddings or Cohere Embed on Bedrock means your embedding calls stay within the AWS network (lower latency, no cross-internet API calls, VPC security groups apply). For financial services, healthcare, and government teams with data residency requirements, this matters.

Where OpenSearch is weaker than Elasticsearch: neural sparse retrieval (the ELSER equivalent) is maturing but lags ELSER v2 on benchmarks. The hybrid search pipeline configuration is more verbose. Some advanced Elasticsearch 8.x query DSL features are not available. Community and documentation density is lower than Elasticsearch — Stack Overflow, blog posts, and tutorials for Elasticsearch 8.x vector search are significantly more abundant.

The practical migration scenario from Elasticsearch to OpenSearch: teams that were running Elasticsearch 7.x open-source before the 2021 license change, and were forced off the free Elastic open-source build, have found OpenSearch 2.x to be a compatible migration path with moderate rewrite effort (query DSL adjustments, analyzer configs, template migration). If you were on ES 8.x and used Elastic License features, the migration is harder — you lose ELSER and must substitute a neural search pipeline approach.

Typesense wins when search is a feature in your application, not the core platform, and when developer experience and operational simplicity matter more than ML depth or analytics capabilities.

Use Typesense when: your corpus is under 10M documents (sweet spot for in-memory performance without prohibitive RAM costs). When you are building product search, documentation search, or in-app knowledge base search. When your team does not have a dedicated search engineer and needs to be operational in days not weeks. When you are on a startup budget and want to start at $32/month managed rather than $350/month OpenSearch Serverless floor.

Typesense's typo tolerance is class-leading for the application-search use case — better out-of-the-box than Elasticsearch or OpenSearch for prefix/typo queries without custom analyzer configuration. Faceting and filtering performance is excellent. The ranking rule DSL is intuitive. The documentation is concise, practical, and well-maintained. For a developer picking this up for the first time, the time-to-first-search-result is dramatically shorter than Elasticsearch.

The pricing competes well at small-to-mid scale. $32/month managed vs $350/month OpenSearch Serverless minimum is a 10x difference. Self-hosted Typesense with a single $20/month Hetzner server handles most small product search deployments. At these price points, the operational simplicity pays for itself in avoided engineering time within the first month.

Realistic ceiling: if your corpus grows past 20M documents and you need semantic search with auto-embedding, plan to migrate. Typesense is designed for simplicity and will not grow with you to Elasticsearch scale without meaningful re-architecture. The absence of native embedding inference is the most common migration trigger — teams start simple with keyword+vector (passing vectors from OpenAI API), then decide they want ELSER-style auto-embedding and have to migrate to Elasticsearch.

Typesense and the hybrid stack: a common production pattern is Typesense for the interactive search UX (fast, typo-tolerant, faceted product/doc search) plus a separate semantic layer (Weaviate, Qdrant, or Elasticsearch) for retrieval-augmented generation. The two systems serve different query types and can coexist. This is over-engineering for most small teams, but it is the right answer when you need both first-rate interactive search AND deep semantic RAG in the same product.

Migration from Elasticsearch to OpenSearch (for teams leaving after the 2021 license change or seeking Apache 2 purity): the migration is conceptually straightforward — OpenSearch forked from ES 7.10.2 and maintains DSL compatibility at the query level for most standard operations. In practice: (1) Audit your query DSL for ES 8.x features not in OpenSearch 2.x — aggregations like composite sources, EQL, some scripted metric aggs behave differently or are absent. (2) Mapping templates and index lifecycle management (ILM in ES, ISM in OpenSearch) are different — rewrite your templates. (3) Security configuration is entirely different (Elasticsearch Shield/X-Pack vs OpenSearch Security plugin). (4) Kibana → OpenSearch Dashboards migration is mostly UI-parity but dashboard JSON is not always portable. Expect 2-6 weeks of eng time for a non-trivial production migration.

Migration from Elasticsearch to Typesense: this is a significant architectural shift, not a drop-in swap. Typesense's collection schema is simpler than Elasticsearch mappings — most text and numeric fields translate directly, but nested objects, parent-child relationships, and complex analyzers do not. The query DSL is entirely different (Typesense uses a simple JSON params API, not Elasticsearch query DSL). If you have extensive custom scoring, function_score, or analytics aggregations, these do not translate. Realistic timeline: 4-12 weeks for a medium-complexity production search feature, depending on custom scoring and aggregation dependencies.

Migration from Elasticsearch to OpenSearch specifically for vector workloads: the kNN plugin configuration syntax differs from Elasticsearch's dense_vector. Elasticsearch uses field type `dense_vector` with `index: true` and `similarity` config; OpenSearch uses a `knn_vector` field type with `space_type` and `ef_construction` params. Re-index is required (you cannot move index files). ELSER-indexed sparse_vector fields have no OpenSearch equivalent — you must decide whether to use neural sparse (if quality is adequate) or switch to dense vector + external embeddings.

The most common migration mistake: attempting a zero-downtime migration without testing query result parity first. Build a shadow-traffic system that runs identical queries against both engines and compares result sets before cutting over. Even between ES and OpenSearch, ranking differences in BM25 scores (due to shard count, IDF differences, and scoring normalization) can cause visible result quality regressions.

Migration from OpenSearch or Elasticsearch to a purpose-built vector database (Pinecone, Weaviate, Qdrant): if your use case has become primarily vector search with minimal full-text BM25 requirements, a dedicated vector DB may be more cost-efficient. Compare the cost and operational overhead with our Pinecone vs Weaviate vs Qdrant comparison before committing to a migration path.

A word on vendor stickiness: all three platforms require re-indexing to migrate (there is no shared on-disk index format). For large corpora (100M+ documents), re-indexing is measured in days of compute time and significant egress costs if moving cloud regions. The switching cost is real. Pick carefully, and treat a search platform decision as at least a 2-3 year commitment.

Pricing in this guide is sourced as follows. **Elasticsearch / Elastic Cloud**: elastic.co/pricing, fetched 2026-06-21. Elastic moved from Apache 2 to dual-license (Elastic License 1.0 + SSPL) in January 2021, then to Elastic License 2.0 in 2022. Elastic Cloud pricing has been restructured multiple times; the $95/month figure is an approximation for the smallest IO-optimized deployment in us-east-1 as of June 2026. Elastic License 2.0 terms allow commercial internal use without a paid subscription but prohibit providing the ML-licensed software as a service to third parties.

**Amazon OpenSearch Service and OpenSearch Serverless**: aws.amazon.com/opensearch-service/pricing/, fetched 2026-06-21. OpenSearch forked from Elasticsearch 7.10.2 in April 2021. OpenSearch Serverless launched in 2023 and the OCU pricing model ($0.24/OCU-hour) and 2-OCU-minimum have been consistent since launch — verify the current floor at the AWS pricing page before procurement, as AWS does adjust managed service pricing. Self-managed EC2 instance prices cited ($0.10/hour for t3.small.search) are from the published Amazon OpenSearch Service instance pricing table.

**Typesense**: typesense.org/pricing, fetched 2026-06-21. Typesense Cloud launched managed hosting in 2022. The $0.044/hour RAM1 tier entry price has been stable. Typesense server code was re-licensed from GPL-3 to Apache 2 in 2021; some client SDKs moved to BSL 1.1 in late 2024. Vector search was added in Typesense v0.25 (2023). The 1,536 max dimension limit aligns with OpenAI text-embedding-3 dimensionality — verify the current limit in the Typesense documentation if you are using higher-dimension models.

All prices cited are for us-east-1 or equivalent default region. Multi-region deployments, data transfer costs, and premium support tiers add cost not reflected in entry pricing. All licensing summaries are editorial interpretations of the published license texts, not legal advice — consult your legal team before making procurement decisions based on license terms.

**Live-verify before procurement**: open each vendor's pricing page and documentation and confirm the figures in this guide. Search infrastructure pricing can change, and all three platforms have released significant feature updates in the past 12 months. The links to vendor pricing pages in the footnote of the comparison table above are the authoritative sources.