OpenSearch

Editor’s note: This OpenSearch review is based on my hands-on test of OpenSearch 3.9.0, released September 29, 2026, on my laptop: install, plugins, a million log events, DSL, SQL and PPL queries, and vector search. I weigh pricing, setup, search and analytics, vectors, operations and security.

Quick verdict: I recommend OpenSearch for teams that want Elasticsearch-style search and log analytics under Apache 2.0, with security, alerting and vector search included free. Self-hosting means owning plugin versions, shards, heap and upgrades; Amazon OpenSearch Service takes that over but bills per instance hour.

OpenSearch is the Apache 2.0 fork of Elasticsearch 7.10, governed since September 2024 by the Linux Foundation’s OpenSearch Software Foundation (premier members: AWS, SAP, Uber, IBM).

Key Takeaways:

• I loaded 1 million log events in 22.9 seconds on one laptop node; the index took 85 MB.
• No paid tier, Security plugin included; a managed r7g.large.search node costs $0.178/hour (us-east-1, on-demand).
• SQL and PPL answered my 5xx questions without query DSL.
• There is no official macOS build; the Homebrew formula is the bare engine, with HTTP open and no authentication.
• A Faiss index on my Homebrew build with the Maven k-NN plugin crashed the whole node, which crash-looped until I removed the plugin.

In this review, I’ll take a closer look at OpenSearch’s pricing, setup, search, vectors and day-two operations, so you can see whether it beats Elasticsearch, ClickHouse or a managed host for your workload.

Pros and Cons

How Much Does OpenSearch Cost?

OpenSearch costs $0 under Apache 2.0, with every feature included and no enterprise edition. You pay for compute and storage, or for a managed service:

• Self-hosted ($0): for teams with ops capacity. Every open-source feature is included; servers, storage and upgrades are yours to run.
• Amazon OpenSearch Service (from $0.036/hour): for AWS shops that want managed domains. That buys a t3.small.search dev node; a memory-optimized r7g.large.search costs $0.178/hour per node. Both are us-east-1 on-demand prices.
• OpenSearch Serverless ($0.24/OCU-hour): for spiky or idle-heavy workloads. That is the us-east-1 on-demand rate. NextGen collections have no minimum and scale to zero after 10 idle minutes; Classic collections bill a two-OCU minimum, or 0.5 indexing plus 0.5 search in dev-test.
• Aiven for OpenSearch ($0 to $1,140+/month): for multi-cloud managed hosting. Free gives one shared node and 20 GB on DigitalOcean only; Developer is $40/month, Startup from $90, Business from $275 and Premium from $1,140.

Every AWS row below is a us-east-1 on-demand price. Monthly figures assume 730 hours, and instance prices exclude storage.

Option	Price	What you get	Best for
Self-hosted OpenSearch	$0 software license	All features; you run it	Teams with operators
AWS t3.small.search (us-east-1 on-demand)	$0.036/hour, about $26/month	Burstable dev node	Dev and test
AWS m7g.large.search (us-east-1 on-demand)	$0.135/hour, about $99/month	General-purpose node	Balanced workloads
AWS r7g.large.search (us-east-1 on-demand)	$0.178/hour, about $130/month	Memory-optimized node; three cost about $390/month before storage	Production sizing
AWS gp3 EBS (us-east-1 on-demand)	$0.122/GB-month	Hot storage	Active indexes
AWS UltraWarm/managed storage (us-east-1 on-demand)	$0.024/GB-month	Warm-tier storage; UltraWarm nodes bill extra	Longer retention
AWS Serverless (us-east-1 on-demand)	$0.24/OCU-hour	Classic two-OCU minimum about $350/month; NextGen scales to zero	Variable demand
Aiven Startup	From $90/month	Managed OpenSearch, multi-cloud	Small managed deployments

Three r7g.large.search nodes at about $390/month is not a production quote: dedicated cluster manager nodes and storage come on top. UltraWarm also bills compute, from $0.238/hour for ultrawarm1.medium.search (us-east-1, on-demand), on top of the storage rate.

Is OpenSearch Good Value for Money?

• Free security is the real saving. OpenSearch has no paid software tier, while Elastic gates advanced features behind paid subscriptions.
• Reserved instances reward steady load: AWS discounts run 31-35% for one year and 48-52% for three years, depending on how much you pay upfront.
• Short-lived domains pay for rounding: partial instance hours bill as full hours.
• Old engine versions cost extra: Extended Support adds $0.0065 per normalized instance hour (us-east-1, on-demand).
• Elastic Cloud Hosted starts at $99/month for a 120 GB, two-zone configuration, so compare whole deployments, not that entry price against one AWS node.

Reviewer’s Notes: For development, I’d use Docker or a t3.small.search domain. For production logs, I’d size-test three r7g.large.search data nodes with gp3 storage and add UltraWarm once retention passes about 30 days. Serverless NextGen is the option I’d shortlist for intermittent vector or RAG workloads because it scales to zero, but for steady traffic I’d price it against instances first. I did not test AWS, Serverless or Aiven, so treat these as sizing starting points, not measured bills.

My Experience With OpenSearch

Installing OpenSearch on a Mac

I went the Homebrew route because OpenSearch offers no macOS build: the official downloads are Linux and Windows tarballs, packages and Docker images. Homebrew gave me OpenSearch 3.9.0 with Lucene 10.5.1 on OpenJDK 25.0.5, taking about 190 MB plus 371 MB for the JDK.

On a single node with a 1 GB heap, the REST API answered 13 seconds after a cold start and 9 seconds on later restarts.

What surprised me was how bare the formula is. There was no Security plugin, no Dashboards, no k-NN and no SQL, and port 9200 answered with no authentication at all. Keep that setup on localhost and never bind it to a public interface.

The official bundle is stricter. Since 2.12 it refuses to start without OPENSEARCH_INITIAL_ADMIN_PASSWORD (8-100 characters, rated strong), and Linux hosts need vm.max_map_count=262144. I did not run the bundle, so those are documented requirements, not steps I took.

My laptop disk was 99% full, which is a trap on laptops and small VMs: the default 95% flood-stage watermark makes indexes read-only. I started the node with cluster.routing.allocation.disk.threshold_enabled=false to finish the test; on a real server, free the disk instead.

Adding Plugins

I added k-NN and SQL with opensearch-plugin install from Maven Central, and each had to match the engine exactly: 3.9.0.0, not any 3.x build. The SQL install failed first with Missing plugin [opensearch-job-scheduler], dependency of [opensearch-sql]. Installing job-scheduler first fixed it, and SQL queries worked from then on.

Record the engine and plugin versions together before every upgrade. As the Faiss crash below shows, a plugin problem on OpenSearch does not always stop at a refused install.

Loading a Million Log Events

I generated 1,000,000 synthetic web-access events (timestamp, status, path, method, country, latency, bytes, a short free-text message and a user agent) and loaded them with a single-threaded Python client. I set an explicit mapping instead of letting OpenSearch guess field types, with these index settings:

{"settings":{
  "number_of_shards":1,
  "number_of_replicas":0,
  "refresh_interval":"30s"
}}

Each _bulk request carried 5,000 documents. The load took 22.9 seconds end to end, about 43,700 documents per second including client-side document generation, with zero bulk errors.

After refresh, the index occupied 85 MB (86.3 MB after a restart). Those are compact synthetic logs with no replicas, so don’t use that figure to predict storage for real messages on a replicated cluster; open-source OpenSearch defaults to one replica, a second full copy of every shard.

Reviewer’s Notes: The core engine impressed me: one laptop node started in 13 seconds and took a million log events without a single bulk error. The friction sat around it: no security on the Homebrew build, a plugin dependency the installer did not resolve, and platform-specific native libraries. For a representative evaluation, I’d start from the official Docker image rather than Homebrew’s bare engine.

Search, Aggregations, SQL and PPL

🔎 Full-Text Search

A match query for "payment declined" filtered to status >= 500 returned 20,295 hits in 75 ms across the million-document index. Scored text matching plus a structured filter in one request, on a laptop node with a 1 GB heap, is the main reason to run OpenSearch next to a SQL database.

ClickHouse is the stronger pick for pure SQL aggregation over events, but it is not a relevance engine. When message text matters as much as the counts, OpenSearch handles both in one index.

📊 Aggregations

A terms aggregation on path, ordered by p95 latency with a 5xx filter sub-aggregation, took 238 ms. The top bucket was / with a p95 of about 206 ms and 5,098 server errors, and the bucket counts added up to exactly 1,000,000.

A daily date_histogram with a country cardinality sub-aggregation took 52 ms and counted 8 distinct countries per day, the quickest of my three DSL queries.

Query	What it does	Result on 1M documents
Full-text match plus status filter	Finds “payment declined” among 5xx responses	20,295 hits in 75 ms
Terms plus p95 and 5xx filter aggregations	Ranks paths by p95 latency with error counts	238 ms
Daily histogram plus cardinality	Distinct countries per day	52 ms
SQL GROUP BY	Top three paths by 5xx count	Top: /blog/opensearch-3, 5,131 errors; no timing recorded
PPL pipeline	Top three countries by 5xx count	Top: IN, 5,140 errors; no timing recorded

Each number is one warm-ish run on a single node. Use them to justify a workload trial, not as a throughput promise or a win over Elasticsearch.

🧮 SQL and PPL

My SQL query grouped 5xx responses by path and returned the top three, led by /blog/opensearch-3 with 5,131 errors. Running _explain on a simpler COUNT(*) query showed it compiles to a normal term query plus an aggregation, so SQL reads the same index as the DSL with no separate analytical copy.

PPL worked too: source=weblogs | where status >= 500 | stats count() as n by country | sort - n | head 3 put IN first with 5,140 errors. I like the pipe syntax for quick log triage; Elasticsearch covers similar ground with ES|QL.

Version 3.7 added a DataFusion-based distributed analytics engine and more PPL commands, and 3.9 adds MPP-style distributed joins and aggregations. I did not test distributed analytics, so for SQL-first workloads I’d benchmark ClickHouse separately rather than extrapolate from one node.

Vector and Hybrid Search

I indexed 20,000 random 128-dimension vectors on the Lucene engine in 4.9 seconds, using HNSW with m=16, ef_construction=100 and L2 distance. The first k=10 query took 67 ms and returned the exact self-match with a score of 1.0. A k-NN query with a keyword term filter took 15 ms and returned only the filtered category.

A later rebuild of the same index took 5.6 seconds, with 131 ms for the first query, so read these as single runs, not latency targets. The index settings showed derived source switched on, the 3.x default for vector indexes. Random vectors prove the plumbing works; they say nothing about embedding quality or RAG relevance.

Faiss went badly. OpenSearch accepted my Faiss index and mapping, then the first bulk write threw UnsatisfiedLinkError: no opensearchknn_faiss in java.library.path and took down the whole node, not just the request.

The cause matters. I was on the Homebrew build with the k-NN plugin from Maven, and that plugin zip has no macOS native library; the official Linux and Windows bundles ship the Faiss library, and I did not test Faiss on them. My complaint is the failure mode: an index the engine had accepted crashed the process instead of failing with an error.

OpenSearch documents more vector features than I tested:

• Neural and hybrid search: the ML Commons and neural search plugins add model-backed and hybrid retrieval.
• Native sparse engine: 3.9 adds a C++ neural sparse engine.
• Vector formats: 3.9 adds half_float vectors and 2-bit and 4-bit scalar quantization alongside 1-bit.
• GPU index builds: experimental since 3.0.

I did not test neural, hybrid, quantization or GPU features. Before choosing OpenSearch for RAG, run a relevance evaluation with real embeddings, especially if filters decide which documents a user may see.

OpenSearch vectors make the most sense for teams already running it for text search or logs. Vespa is my pick for complex hybrid ranking at scale, and a Pinecone-style managed vector database wins if you’d rather not run a cluster at all.

Plugins, Shards and Upgrades: The Operational Bill

After the Faiss crash, my node crashed again about nine seconds into every restart while recovering the Faiss shard. I removed the k-NN plugin, started the node and deleted the Faiss index, and the million-document log index came back green with every document.

The Lucene vector index did not survive. Removing k-NN made OpenSearch archive that index’s k-NN settings, and after I reinstalled the plugin it stayed red. OpenSearch refused to fix it because index.knn is a final setting (“not updateable”), so I deleted the index and rebuilt it from source data.

My lesson is blunt: keep source data replayable, and never remove a plugin while indexes still depend on it.

For production sizing, start from the documented guidance, not my laptop:

• Search shards: 10-30 GiB where search latency matters.
• Log shards: 30-50 GiB for write-heavy log analytics.
• Shard overhead: AWS recommends no more than 25 shards per GiB of heap.
• Defaults differ: AWS domains default to five primary shards; open-source OpenSearch defaults to one.
• Cluster managers: three dedicated cluster manager nodes across three zones for production.

Primary shard count is hard to change after creation, so size indexes before you commit to retention policies. I did not test multi-node clusters or those shard sizes.

The eight-week minor cadence also means client work. Version 3.8 deprecated RestClient; 3.9 deprecated RestHighLevelClient in favor of opensearch-java and changed too_many_clauses responses to HTTP 400.

No Elasticsearch client is fully compatible with OpenSearch 2.0 or later. The 2.x line stays in maintenance until 4.0, so schedule the 3.x migration test now.

Amazon OpenSearch Service and Aiven absorb the node recovery and upgrade work; that is what their hourly and monthly rates buy. You still own shard design and client compatibility.

Security, Dashboards and Observability

🔐 Security

OpenSearch’s Security plugin is free, with fine-grained access control and role-based access. My Homebrew build did not include it, so I tested an unauthenticated REST API rather than the official distribution’s secured setup.

Evaluate access policies on the official bundle. Elastic gates its advanced features behind paid tiers; OpenSearch’s advantage is that no feature in its open-source distribution needs a subscription.

The demo security configuration is for evaluation only. Production still needs your own certificates and deliberately configured roles.

📈 Dashboards and Observability

OpenSearch Dashboards runs on port 5601, separate from the engine’s REST port 9200. I did not install Dashboards or test these documented features:

• Alerting: monitors, with a unified alerts view in 3.9.
• Anomaly detection and forecasting: surfaced in that same 3.9 alerts view.
• Index state management: policies for index lifecycles.
• Trace analytics: observability workflows with Data Prepper and OpenTelemetry ingest.

None of these carries a license fee, but I can’t rate the Dashboards workflow from an API-only test. Put access controls and alert delivery into any production trial.

Grafana Loki is the alternative when cheap retention matters more than full-text search. It indexes labels only, which keeps storage cheap, but for ad-hoc searches across message text I’d pick OpenSearch.

How Does OpenSearch Compare to Competitors?

OpenSearch earns a shortlist spot for combined text search and log analytics in one Apache 2.0 cluster. Its SQL and vector plugins don’t make it the best specialist in every category.

• Elasticsearch: I’d pick Elastic when integrated APM and SIEM drive the purchase. It has ES|QL, Elastic Cloud Hosted starts at $99/month, and an AGPLv3 license option arrived in August 2024. Version 9.5.5 shipped October 6, 2026. OpenSearch’s Apache 2.0 license remains the simpler permissive choice.
• ClickHouse: the SQL-first columnar database I’d choose for aggregation-heavy event analytics, where my SQL GROUP BY over 5xx paths is the whole job. It is not a full-text relevance engine, its operational model differs, and I did not run a head-to-head speed test.
• Vespa: my shortlist for large-scale hybrid ranking and recommendations, where it gives more control over ranking than OpenSearch’s k-NN plugin. Expect a steeper learning curve and a smaller community.
• Apache Solr: mature faceted search under Apache governance, with a smaller log-analytics and vector ecosystem than OpenSearch.
• Typesense / Meilisearch: app and site search with typo tolerance and instant-search UX, far simpler to set up than an OpenSearch cluster, but not built for log analytics or complex aggregations.
• Grafana Loki: retention-focused logging in a Grafana stack; its label-only index trades full-text search and ad-hoc analytics for cheaper storage.

Tool	License	Best for	Managed starting price
OpenSearch	Apache 2.0	Search plus log analytics	AWS $0.036/hour (us-east-1 on-demand); Aiven Developer $40/month
Elasticsearch	AGPLv3, SSPL or ELv2	Integrated search, APM and SIEM	Elastic Cloud Hosted $99/month
ClickHouse	Apache 2.0	SQL-first event analytics	Varies
Vespa	Apache 2.0	Hybrid ranking and recommendations	Varies
Apache Solr	Apache 2.0	Faceted search	Varies
Typesense / Meilisearch	GPLv3 / MIT core	App and site search	Varies
Grafana Loki	AGPLv3	Label-indexed log retention	Varies

Choose the workload category before comparing entry prices. A $40 Aiven Developer plan, a $99 Elastic Cloud deployment and one bare AWS node are not equivalent capacity.

How I Reviewed OpenSearch

Prices current as of October 2026.

I tested OpenSearch 3.9.0 on October 22, 2026 on my Apple silicon Mac: one node, a 1 GB heap, the Homebrew build plus the k-NN, SQL and job-scheduler plugins.

I loaded one million synthetic log events, ran DSL, SQL and PPL queries, indexed 20,000 vectors on Lucene, tried the same load on Faiss, and recovered the node after the Faiss crash. I weighed pricing, setup, search and analytics, vector search, operations and security.

I did not run Dashboards, the Security plugin, alerting, anomaly detection, multi-node clusters, Amazon OpenSearch Service, Serverless or Aiven, and I did not test neural or hybrid search or Faiss on the official bundle. Those parts describe documented behavior.

Should You Use OpenSearch for Search and Log Analytics?

Yes, if you need relevance search and log analytics under Apache 2.0 and have someone to own the cluster, or a budget for managed hosting. My million-event load and working SQL and PPL queries back that up; the Faiss crash is why I wouldn’t deploy it casually.

It fits AWS-centered teams, organizations that want free security under open governance, and teams on Elasticsearch 7.10-era stacks, provided they test client compatibility instead of assuming a drop-in swap.

Skip it for SQL-first analytics (ClickHouse), integrated APM and SIEM (Elastic) or a small app’s search box (Typesense or Meilisearch). For vectors, OpenSearch makes sense when it already runs your text search. If nobody will own shards, plugin versions and the eight-week upgrade cycle, pay for Amazon OpenSearch Service or Aiven instead.

Start with the official Docker image and the demo security configuration, not Homebrew. Load one day of real logs, then size shards from the resulting index size and query times.

OpenSearch FAQ

Is OpenSearch free?

Yes. OpenSearch is free under Apache 2.0, including the Security plugin, alerting and anomaly detection, with no enterprise edition to unlock. You still pay for servers, storage and maintenance, or for a managed host such as Aiven, whose Developer plan costs $40/month.

Is OpenSearch the same as Elasticsearch?

No. OpenSearch forked from Elasticsearch 7.10.2 in 2021 and now ships separate releases: OpenSearch is on 3.9, Elasticsearch on 9.5. No Elasticsearch client is fully compatible with OpenSearch 2.0 or later, so use OpenSearch clients such as opensearch-java.

How much does Amazon OpenSearch Service cost?

It bills per instance hour plus storage. At us-east-1 on-demand rates, an r7g.large.search node costs $0.178/hour, gp3 storage $0.122/GB-month and Serverless $0.24 per OCU-hour. Partial hours bill as full hours, so price a complete, redundant deployment, not one node.

Can OpenSearch be used as a vector database?

Yes. The k-NN plugin supports the Lucene and Faiss engines; my Lucene test indexed 20,000 vectors in 4.9 seconds and answered a filtered query in 15 ms. Faiss needs the native library in the official Linux and Windows bundles, which my Homebrew build with the Maven plugin lacked.

Does OpenSearch run on macOS?

Not natively: there is no official macOS build, so use Docker or the Homebrew formula. Homebrew ran my log and Lucene vector tests but ships without Security or Dashboards. The official Docker image gives you the bundled features and avoids my native-library crash.