Pinecone vs OpenSearch

Dataset: YFCC10M, 10 million 192-dimension vectors with Euclidean distance. Queries returned the top 10 results, with filters at seven selectivity levels from 0.001% to 0.99% of the corpus. Medians with no writes running come from a pass at 50 queries per second. Tail latency and the figures with writes running combine that pass with a lighter one used to measure recall. Amazon OpenSearch Service ran OpenSearch 3.7 with Lucene HNSW (m of 16, ef_search of 100), three shards with one replica each, and three dedicated master nodes. Its data nodes were either three r7g.large.search with 16 GiB each or three r7g.xlarge.search with 32 GiB each. The write test ran on the 32 GiB nodes. Pinecone ran on the serverless on-demand tier in aws-us-east-1. The write test sent inserts, updates, and deletes in roughly equal parts while queries ran. OpenSearch sustained 422 writes per second. Pinecone committed 358 writes per second of the 448 offered. The rest hit per-namespace rate limits because the harness sent one record per request and did not retry. In a separate Pinecone test with deletes batched and updates sent as upserts, the same mix ran at about 450 writes per second with no failures. Average recall@10 across the filter tiers was 99.8% on OpenSearch, at an ef_search of 100, and 98.9% on Pinecone. Runs took place between August 21 and September 27, 2026.

Results depend on the dataset, query pattern, and configuration. Test your own workload before deciding on these numbers.

How each one stores and serves vectors

OpenSearch stores data in Lucene indexes, splits them into shards, and spreads the shards across nodes. It shares that design with Elasticsearch, which it forked from at version 7.10 in 2021. The design was built for matching terms, aggregating fields, and searching logs at scale. It does those things well.

Vector search runs through the k-NN plugin. In the in-memory configuration, each Lucene segment gets its own vector graph. The graphs load into native memory outside the JVM heap. By default OpenSearch gives them half of the RAM the heap leaves over. Each replica holds a full copy.

Pinecone separates storage from compute. Vectors are written to object storage and served by query servers that Pinecone runs. Growing the corpus and growing query throughput are separate decisions. Neither one requires you to plan a cluster.

Sizing node memory for the vector index

OpenSearch publishes the formula. An HNSW index needs about 1.1 × (4 × dimension + 8 × m) bytes per vector, where m is the number of links each vector keeps in the graph. OpenSearch's own example puts one million 256-dimension vectors at about 1.267 GB. Each replica adds a full copy. The figure also grows with the dimension count of your embedding model.

The share of node RAM that OpenSearch sets aside for those indexes is a limit. When the vector indexes on a node outgrow it, OpenSearch evicts the least recently used ones and loads them again the next time a query needs them. The memory estimate is a sizing requirement to plan around.

Our benchmark used the Lucene engine, which serves vectors from the operating system's page cache (memory the operating system uses to keep recently read files) rather than from that set-aside share. The same rule held. On 16 GiB nodes, after the JVM heap and the operating system took their share, the index was a few hundred MB per node too big for the page cache. The median query at the broadest filter tier took 37 s. On 32 GiB nodes, where the index fit, every filter tier came back to 10 to 16 ms.

OpenSearch has narrowed this. Disk-based vector search, added in 2.17, compresses vectors 32x by default and rescores results against full-precision vectors read from disk, at the cost of slightly higher latency in OpenSearch's own description. Memory-optimized search, added in 3.1, maps the Faiss index file into memory and serves it from the operating system's file cache instead of loading it whole.

Both are choices you make per index. Memory-optimized search covers Faiss HNSW indexes created on 2.19 or later and needs an index restart to switch on or off. Disk-based mode trades latency for memory at a compression level you pick. On Pinecone there is no equivalent setting to manage.

What happens when you write while you query

By default, the same OpenSearch data nodes index new data and answer queries. Each segment carries its own vector graph. Queries search across all of them. OpenSearch's tuning guide recommends turning off the one-second default refresh interval during bulk vector ingest, to avoid creating many small segments.

OpenSearch's engineers are direct about the query side. An open RFC in the k-NN project says customers have to merge segments down to get better performance, calls that an expensive process, and says that even with concurrent segment search the result is "no where close to single segment performance and throughput."

In our benchmark, the 32 GiB cluster sustained about 422 writes per second. Median query latency roughly doubled. The slowest queries at one filter tier reached 5.7 s.

Open source OpenSearch can separate the two workloads. It takes nodes with the search role, a remote store, segment replication, and search replicas on each index. That works. It is also another topology to size and maintain, next to the memory plan above.

Pinecone separates the write path from the read path by design. A write is durable when the API returns and is indexed in the background. There is no refresh interval or merge schedule to manage.

What changes on OpenSearch Serverless

Everything above applies to an Amazon OpenSearch Service domain or a cluster you run yourself. AWS also sells OpenSearch Serverless, in two generations.

NextGen collections, which AWS recommends for new vector collections, decouple compute from storage, with separate capacity for indexing and search. AWS documents that only the data blocks active searches need are loaded into memory, that every index uses 32x compression by default, and that GPU index builds are on by default. There is no minimum capacity. Indexing and search both scale to zero after ten minutes without requests. Classic collections bill a minimum of two OCUs for the first collection in an account.

That removes most of the operational difference between the two products. If you are evaluating NextGen, node planning is not a reason to pick Pinecone. Compare the two on retrieval quality with your own filters, on freshness against your requirement, and on how cost grows at your scale. AWS documents a read-after-write latency of 10 seconds for NextGen vector collections.

What the benchmark does not cover

The runs above use 10 million vectors on Amazon OpenSearch Service domains. NextGen Serverless was not part of them. OpenSearch's memory requirement grows with the corpus, as its formula shows. We have not published a like-for-like run at larger scale.

We have not published a cost comparison either. Cost depends on how you size OpenSearch, whether NextGen Serverless fits your traffic, and which Pinecone tier fits yours. Model both against your own corpus and query rate.

An earlier Pinecone page carried figures from older runs against Amazon OpenSearch Service. We retired them because they predate disk-based vector search, memory-optimized search, GPU index builds, and NextGen Serverless. The results above replace them.

If you want numbers for your own workload, we can run your queries and filters on Pinecone and on a cluster sized like your production one. We measure latency with and without writes, tail latency at your write rate, recall by query type, time from write to searchable, ingest throughput, and cost.

Multi-tenancy scales differently

An application that serves many customers usually has to keep each customer's data isolated. OpenSearch has no tenant primitive below the index. Teams give each tenant its own index or share one index filtered by tenant. On a shared index every tenant shares the same shards and memory. The memory cliff applies to the combined index. With an index per tenant, the shard count grows with the tenant count. AWS advises no more than 25 shards per GiB of Java heap on a node. Node memory has to grow with it.

Pinecone uses namespaces, which are partitions inside a single index. A query runs against one namespace at a time. Adding tenants does not require you to provision capacity for their combined size in advance.

When to stay on OpenSearch

If OpenSearch already runs your logs, observability, or security analytics, keep it there. Pinecone does not replace any of that. The same holds for applications built on OpenSearch aggregations or OpenSearch Dashboards, and for teams that need an Apache 2.0 license.

If the vector workload is small next to that work, adding vectors to the existing domain is the shortest path. NextGen Serverless is also a reasonable choice for spiky or mostly idle workloads, since it scales to zero.

That usually stops holding when retrieval becomes a primary workload. The memory plan, the shard count, and the ingest tuning above become the main cost. Teams usually move that one workload off the cluster and leave the rest where it is.