Itamar Syn-Hershko
Pinecone, Weaviate, Qdrant, and OpenSearch compared, plus the object-storage engines turbopuffer, Amazon S3 Vectors, and WarpSearch, on indexing, hybrid search, quantization, filtering, deployment, and pricing, and when a second vector store is not worth running.
Most teams asking "which vector database" in 2026 should not be adding a database at all. If you already run OpenSearch or Elasticsearch for logs or application search, k-NN is a mapping change and a search pipeline, and the second store you were about to stand up is a sync job that will eventually disagree with the first one about which documents exist. That is our position (we sell OpenSearch work, so weigh it accordingly), and the rest of this post is the evidence for it plus the cases where it is wrong: pure-vector workloads with a small team, and workloads that need the most aggressive compression available today.
Four questions narrow the field: how many vectors, whether retrieval is pure ANN or a blend of keyword and semantic signals, what deployment constraints you carry, and what search infrastructure you already run. This post compares Pinecone, Weaviate, Qdrant, and OpenSearch against those four, then covers turbopuffer, Amazon S3 Vectors, and WarpSearch separately, since engines built on object storage are billed differently. pgvector gets its own treatment in pgvector in production; Milvus and Elasticsearch are left out to keep the table readable. If you need the basics first, start with what a vector database is.
Two designs, and what "hybrid" means
Dedicated ANN engines (Pinecone, Qdrant, Weaviate) are built around upsert and query SDKs and treat metadata as a filter on the index. Search engines with vector support (OpenSearch) start from an inverted index and a query DSL, then add k-NN next to BM25, aggregations, and relevance tuning.
Hybrid search means fusing more than one retrieval signal, typically dense vectors plus lexical BM25 or a learned sparse encoder, through Reciprocal Rank Fusion (RRF) or score normalization, sometimes followed by a cross-encoder reranker. Vectors plus a metadata filter does not qualify. The fusion step is where engines differ. OpenSearch has done this since 2.11 through a search pipeline with a normalization processor or an RRF score-ranker processor. Qdrant's Query API fuses dense and sparse prefetches with RRF or DBSF in one request. Pinecone documents three patterns: filter on a BM25 text field and rank by dense similarity, fuse keyword and dense results client-side with RRF, or combine dense and sparse vectors server-side, in one index or two linked by ID.
Why leaderboards do not predict your p95
ANN-Benchmarks reports recall against queries per second for single queries on one machine with no filters. VectorDBBench gets closer to a database workload but still runs a clean setup. Neither measures filtered recall on a tenant_id that matches 0.1% of the corpus, p95 under concurrent writes, or cold-start latency, and those are the numbers that page you. Replay real queries against a brute-force baseline, measure top-k overlap, and load-test at the concurrency you expect.
Filtering is where we see most production vector deployments fall over. Pre-filtering runs the predicate first and searches the survivors, which keeps recall but degrades on selective filters. Post-filtering searches first and drops non-matches, which silently loses recall. Filter-aware traversal evaluates the predicate inside the graph walk. Filter-aware traversal is now standard: Pinecone has done single-stage filtering for years, Weaviate made ACORN the default in 1.34, and OpenSearch does efficient filtering on Lucene, Faiss, and JVector, with Lucene and Faiss choosing between exact and approximate search per query and Faiss adding an ACORN-style optimization in 3.1. The engines still differ on very selective filters and on how much you can tune.
Quantization mainly saves memory. A 768-dimensional float32 vector is 3,072 bytes, so one million of them is 3.07 GB before graph overhead. Scalar 8-bit quantization cuts that 4x. Binary quantization cuts it up to 32x, but you pay it back with oversampling and a rescoring pass. Qdrant's docs report 0.98 recall@100 with 4x oversampling on OpenAI ada-002 embeddings. OpenSearch's binary quantization offers 1, 2, or 4 bits per dimension (32x, 16x, 8x), an oversample_factor rescore parameter, and, since 3.2, random rotation and (at 1 bit) asymmetric distance computation to recover recall. For the index-structure trade-offs, see HNSW vs IVFFlat and scaling vector search from millions to billions.
Head-to-head comparison
Each cell was checked against the linked vendor documentation on 2026-10-25. The engines ship monthly, so re-read the linked pages before you sign anything.
| Capability | Pinecone | Weaviate | Qdrant | OpenSearch |
|---|---|---|---|---|
| Index | Managed serverless, optional Dedicated Read Nodes | HNSW | HNSW | HNSW and IVF on Faiss (default) or Lucene; DiskANN via the JVector plugin |
| Hybrid | BM25 filter then dense rank, client-side RRF, or server-side dense + sparse | Native hybrid query | Native dense + sparse fusion (RRF, DBSF); BM25 as a sparse encoder, no inverted-index scoring | Native BM25 + k-NN + neural sparse with normalization or RRF |
| Quantization | Not user-configurable | PQ, BQ, SQ, RQ (8/4/1-bit) | Scalar, PQ (up to 64x), binary (1/1.5/2-bit), TurboQuant (8/4/2/1.5/1-bit) | fp16 scalar, PQ, binary 1/2/4-bit (Faiss); compression_level up to 32x, on_disk mode |
| Filtering | Single-stage (filter-aware) | ACORN, default since 1.34 | Payload-indexed, filter-aware | Efficient filtering on Lucene, Faiss, JVector (auto exact/approximate on Lucene and Faiss) |
| Deployment | Managed only; pods unavailable to new customers since Aug 2025 | OSS, Cloud (Shared or Dedicated), BYOC | OSS, Cloud, Hybrid Cloud (BYOC) | OSS, Amazon OpenSearch Service (managed and Serverless), other vendors |
| License | Closed source | BSD-3-Clause core | Apache 2.0 | Apache 2.0 |
On OpenSearch engines: Faiss is the default and carries the quantization options, Lucene is pure Java and simpler at smaller scale, and NMSLIB is deprecated. JVector, which brings DiskANN-style on-disk search with native PQ, ships as a separate plugin that cannot be installed alongside opensearch-knn, so it is a cluster-level decision rather than an index-level one.
Object-storage engines: turbopuffer, S3 Vectors, and WarpSearch
These engines store every vector in S3-class object storage, load an index into NVMe or memory when it is queried, and unload it when idle, so an unused index costs only its storage. The downside is cold queries: the first request against an unloaded index waits for the reload.
turbopuffer runs search for Notion (10B+ documents across 10M+ namespaces) and Linear. Amazon S3 Vectors, GA since December 2025, is the cheapest place on AWS to park vectors you rarely query. WarpSearch is a serverless hybrid search service built by our team, so weigh that row accordingly. Cells were checked against the linked docs on the same date.
| Capability | turbopuffer | Amazon S3 Vectors | WarpSearch |
|---|---|---|---|
| Index | SPFresh, a centroid-based ANN index; ANN v3 nests clusters in a tree | Managed, not exposed | IVF over quantized codes, every candidate rescored at full precision |
| Hybrid | BM25 + vector via multi_query with server-side RRF, or a managed reranker |
None; pair with Amazon OpenSearch Service for keyword search | BM25 + kNN with RRF or min-max linear fusion |
| Quantization | Not user-configurable; RaBitQ applied internally; stores f32, f16, or i8 | Not exposed | PQ by default, RaBitQ opt-in; stores f32, f16, bf16, or int8; Matryoshka truncation |
| Filtering | Native filtering, cluster-aware, targets 90%+ recall | ENHANCED indexes pre-filter (default for buckets created since Sep 30, 2026); CLASSIC indexes may return fewer than top-k | Applied while neighbors are collected; exact: true for very selective filters |
| Deployment | Managed multi-tenant; single-tenant or BYOC on AWS, GCP, Azure on Enterprise | AWS only | Managed serverless; BYOC on AWS, Google Cloud, or Azure |
| License | Closed source | Closed source (AWS service) | Closed source (managed service) |
| Scale limits | 128B documents per namespace, 250M+ namespaces observed (limits) | 2B vectors per index, 4,096 dimensions, top-k up to 10,000 (limits) | Plan-dependent |
| API | Own API and SDKs | AWS SDK | Elasticsearch, OpenSearch, Solr, and turbopuffer compatible |
Each fits a different workload. turbopuffer's per-namespace billing fits millions of small tenant indexes. S3 Vectors fits large corpora queried a few times a minute where sub-second latency is good enough, and it has no keyword search of its own. WarpSearch fits large, frequently queried hybrid indexes and teams that want to keep an Elasticsearch or OpenSearch client. We go through turbopuffer's pricing line by line, with alternatives, in turbopuffer pricing and alternatives.
Pricing shapes
Figures below were read from the linked pages on 2026-10-25 and are list prices in US regions.
- Pinecone meters read units, write units, and storage. Starter is free, Builder is a $20/month flat plan, Standard and Enterprise carry $50 and $500 monthly minimums. On Standard, read units run $16-18 per million, write units $4-4.50 per million, storage $0.33/GB-month. Read units scale with query volume, top-k, and namespace size, so high-QPS workloads are the bill to watch; Dedicated Read Nodes turn that into provisioned capacity.
- Weaviate Cloud simplified its plans in late 2025. The pricing page now lists Free, Flex (pay-as-you-go from $45/month), and Premium (Shared or Dedicated, prepaid, from $400/month).
- Qdrant Cloud bills hourly for cluster compute, memory, and storage with a free tier, per qdrant.tech/pricing. No per-query metering, so cost tracks capacity, and quantization lowers the bill directly by shrinking RAM.
- OpenSearch spans the widest range. Self-hosted is infrastructure cost only. Amazon OpenSearch Service bills per instance-hour plus storage. OpenSearch Serverless bills $0.24 per OCU-hour; classic collections floor at 2 OCUs with redundancy, while NextGen collections, GA since May 2026, scale to zero after 10 idle minutes and take 10-30 seconds to wake. The old "serverless has a floor cost" objection now only applies to classic collections or to workloads that cannot absorb a cold start.
- turbopuffer bills $1 per PB queried, where each query counts the full namespace size (1.28 GB minimum), plus $0.33/GB-month stored and $2.00/GB written. Plans carry $16, $256, and $4,096 monthly minimums, and there is no free tier. Volume discounts kick in above 32 GB queried per request. For namespaces between 1.28 GB and 32 GB, a million queries cost about $1 per GB of namespace, so the bill tracks index size as much as traffic.
- Amazon S3 Vectors bills $0.06/GB-month stored, $0.20/GB written (128 KB minimum per request), and $2.50 per million queries, plus a small per-TB data-processed fee that falls as indexes grow and a data-returned fee on large result sets. No minimum.
- WarpSearch bills $2 per million requests regardless of index size, $0.08/GB-month stored, and $1.00/GB written (first-tier rates that drop above 1 TB), with a $10 monthly minimum. The free tier covers one collection with 1 GB stored and 100K requests a month.
Self-hosted OpenSearch or Qdrant wins on infrastructure cost at scale; Pinecone and managed Weaviate win on engineer-hours.
OpenSearch as the dual-use store: our take
If you already run OpenSearch, adding k-NN is a small step: the vector field is a mapping, hybrid retrieval is a search pipeline, and the security model, dashboards, and backups you already have apply to the new index. Most real RAG and search systems need BM25, structured filters, and aggregations anyway, and a converged store removes the failure mode where the lexical index and the vector index drift apart. We wrote up the tuning work for this in scaling vector search with OpenSearch.
OpenSearch still lags in a few places. Binary and on-disk modes need oversample_factor tuning per embedding model, with less published guidance than Qdrant offers, and Qdrant's TurboQuant and 1.5-bit options have no OpenSearch equivalent today. The client SDKs are search-engine SDKs, so the upsert-and-query loop is more verbose than Pinecone's or Qdrant's. Index-per-tenant hits shard and cluster limits well before a dedicated engine's namespace model does, and filter-per-tenant needs document-level security. NextGen Serverless trades the OCU floor for a cold start that a latency-sensitive endpoint cannot accept. Picking JVector means giving up the standard k-NN plugin on that cluster. If your workload is pure vector, your team is small, and none of the search-engine features are on the roadmap, a dedicated engine is less work. If you already run search, a second vector database mostly adds a sync job and another system to operate.
Which one, by workload
- Prototype or hackathon, under ~1M vectors. Qdrant in Docker, which can carry into production, or OpenSearch in Docker if you also need keyword search. Neither needs a cloud account.
- Production RAG, strict SLA, small platform team, no existing search stack. Pinecone Serverless for pure vector; Weaviate Cloud when hybrid retrieval has to be native and managed.
- Keywords + semantics + filters + aggregations, or an existing OpenSearch or Elasticsearch deployment. OpenSearch k-NN with a hybrid search pipeline. Do not stand up a second store.
- On-prem, air-gapped, or data-sovereign. Qdrant, Weaviate, or OpenSearch self-hosted; Qdrant Hybrid Cloud and Weaviate BYOC add a managed control plane on your infrastructure.
- Billions of vectors under cost pressure. Qdrant with binary or TurboQuant compression, or OpenSearch Faiss with binary quantization and on-disk mode. Either way, budget for the oversampling and rescoring work.
- Millions of small per-tenant indexes, mostly idle. turbopuffer, whose query cost scales with namespace size, so small, mostly idle namespaces stay cheap. Budget for cold-query latency.
- Large vector corpus, queried rarely, latency-tolerant. Amazon S3 Vectors, or Amazon OpenSearch Service with the S3 Vectors engine if you also need keyword search.
- Serverless hybrid search on a large, busy index, or an Elasticsearch/OpenSearch client you want to keep. WarpSearch (ours), with flat per-request pricing.
You will revisit this decision, so plan the exit. Raw vectors are portable; metadata schemas and filter semantics are not, so keep raw vectors next to source documents and map the schema early. After a migration, replay the same queries on both systems and compare top-k overlap rather than assuming two HNSW implementations agree.
If you are weighing a converged OpenSearch deployment against a dedicated vector database for a production workload, our team can run that evaluation and the tuning that follows.
Frequently Asked Questions
What is the best vector database for RAG?
If you already run OpenSearch or Elasticsearch, use its k-NN with a hybrid search pipeline rather than adding a second store. For production RAG with no existing search stack and a small team, Pinecone Serverless fits pure-vector workloads and Weaviate Cloud fits managed native hybrid retrieval.
Is OpenSearch a good vector database?
Yes. OpenSearch supports HNSW and IVF on Faiss or Lucene, DiskANN via the JVector plugin, native hybrid search combining BM25, k-NN and neural sparse since 2.11, filter-aware efficient filtering, and binary quantization at 1, 2 or 4 bits per dimension with up to 32x compression.
Do I need a dedicated vector database?
Usually not if you already run a search engine, since a second store becomes a sync job that drifts from the first. A dedicated engine such as Pinecone, Qdrant or Weaviate is less work when the workload is pure vector, the team is small, and no search-engine features are on the roadmap.
What is hybrid search in a vector database?
Fusing more than one retrieval signal, typically dense vectors plus lexical BM25 or a learned sparse encoder, through Reciprocal Rank Fusion or score normalization, sometimes followed by a cross-encoder reranker. Vectors plus a metadata filter does not qualify as hybrid.
Which vector database is cheapest?
Self-hosted OpenSearch or Qdrant win on infrastructure cost at scale, while Pinecone and managed Weaviate win on engineer-hours. Entry points are Pinecone Builder at $20 per month, Weaviate Flex from $45 per month, and Qdrant Cloud with a free tier and hourly capacity billing. For storage alone, Amazon S3 Vectors is cheapest at about $0.06 per GB-month; among serverless engines, turbopuffer starts at a $16 monthly minimum and WarpSearch has a free tier and a $10 minimum.
What is turbopuffer?
turbopuffer is a closed-source, serverless search engine for vector and BM25 full-text search that stores data on object storage and caches hot namespaces on NVMe and in memory. It bills each query by the size of the namespace it searches, at $1 per PB with a 1.28 GB minimum, and runs search for Notion and Linear.
Which vector databases are open source?
Qdrant and OpenSearch are Apache 2.0, and Weaviate's core is BSD-3-Clause. Pinecone is closed source and managed only, with pod-based indexes unavailable to new customers since August 2025. turbopuffer, Amazon S3 Vectors, and WarpSearch are closed-source managed services.
