A 2026 comparison of Pinecone, Weaviate, Qdrant, OpenSearch, and Chroma on indexing, hybrid search, quantization, filtering, deployment, and pricing - verified against current vendor docs, with a clear position on 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, OpenSearch, and Chroma against those four. 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.
Three tiers, and what "hybrid" actually 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. Embedded stores (Chroma) optimize for getting to a working prototype in an afternoon; Chroma has a hosted tier now, but the design center is still the single process.
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: sparse-dense in a single index (dotproduct metric only), separate dense and sparse indexes merged client-side with RRF, or a document schema with BM25 fields. Chroma Cloud's search API supports sparse vectors and RRF alongside its full-text and regex filters.
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. In 2026 filter-aware is the norm rather than the differentiator: Pinecone calls it single-stage filtering, Weaviate made ACORN the default in 1.34, and OpenSearch does efficient filtering on Lucene, Faiss, and JVector, choosing between exact and approximate search per query and applying an ACORN-style optimization since 3.1. What still differs is behavior on extremely selective filters and how much of it you can tune.
Quantization is the other lever, and it is mostly a memory lever. 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 asymmetric distance computation and random rotation to recover recall at 1 bit. 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-08-28. The engines ship monthly, so re-read the linked pages before you sign anything.
| Capability | Pinecone | Weaviate | Qdrant | OpenSearch | Chroma |
|---|---|---|---|---|---|
| Index | Managed serverless, optional Dedicated Read Nodes | HNSW | HNSW | HNSW and IVF on Faiss (default) or Lucene; DiskANN via the JVector plugin | HNSW locally, SPANN in Cloud |
| Hybrid | Sparse-dense single index (dotproduct), or separate indexes with client-side RRF | 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 | Full-text and regex filters; sparse + RRF in Cloud search API |
| Quantization | Not user-configurable | PQ, BQ, SQ, RQ (8/4/1-bit) | Scalar, PQ (up to 64x), binary (1/1.5/2-bit), TurboQuant (4/2/1.5/1-bit) | fp16 scalar, PQ, binary 1/2/4-bit (Faiss); compression_level up to 32x, on_disk mode |
Not exposed |
| Filtering | Single-stage (filter-aware) | ACORN, default since 1.34 | Payload-indexed, filter-aware | Efficient filtering on Lucene, Faiss, JVector (auto exact/approximate) | Metadata where filter |
| 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 | OSS embedded, Chroma Cloud (GA Aug 2025) |
| License | Closed source | BSD-3-Clause | Apache 2.0 | 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.
Pricing shapes
Rates change; the shape of the bill changes less. Figures below were read from the linked pages on 2026-08-28.
- 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 provisioned 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.
- Chroma is free embedded. Chroma Cloud charges $2.50/GiB written, $0.33/GiB-month stored, $0.0075/TiB queried, and $0.09/GiB egress; Starter is $0 plus usage with $5 in credits, Team is $250/month plus usage.
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
When OpenSearch is already in the building, k-NN is incremental: 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.
Where it lags is narrower than a year ago, but real. 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 are a search shop, a second vector database is a liability dressed up as a best practice.
Which one, by workload
- Prototype or hackathon, under ~1M vectors. Chroma embedded, or Qdrant in Docker if you want something you will not have to replace. 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.
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 does exactly this evaluation and tuning.
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, Chroma Cloud Starter at $0 plus usage, and Qdrant Cloud with a free tier and hourly capacity billing.
Which vector databases are open source?
Qdrant, OpenSearch and Chroma are Apache 2.0, and Weaviate is BSD-3-Clause. Pinecone is closed source and managed only, with pod-based indexes unavailable to new customers since August 2025.
