Vector Database for RAG: Pinecone vs Qdrant vs pgvector (2026)

Every few weeks the same victory thread goes around: cancelled Pinecone, moved to pgvector on a cheap box, the bill dropped to a rounding error, everything kept working. The replies fill with people who did exactly the same. They are right about their own system, and the move that rescues one team buries the next under a database that stops scaling. The best vector database for RAG is the one that fits your hardest constraint, and the loudest advice on your feed describes someone else's.

We chose Qdrant for our own matcher. That choice answered two questions about our situation, and for a different situation the answer would have been Postgres, or Pinecone, or a plain library. So before the table, the two questions that decide it.

The first is whether your data is allowed to leave your infrastructure. If a client says the documents must stay inside infrastructure they control, you have just eliminated the managed-only category, Pinecone's standard service included, however good it is.

The second is scale and what you already run. With Postgres already in production the boring answer wins more often than people expect, and it wins further up the curve than it used to: pgvector with pgvectorscale carries Postgres into the tens of millions of vectors; its vendor's published benchmark ran 50 million. You reach for a purpose-built engine when retrieval quality itself is the product, when selective filters have to keep their recall, or when you are heading past that range. Most of the rest is detail.

Two questions pick your vector database for RAG: can the data leave the building, and how big does this get. A third decides whether the choice survives production: what comes back when a filter keeps one row in a hundred.

What the vector database does in a RAG pipeline

A RAG pipeline cuts your documents into chunks, turns each chunk into a vector, and stores the vectors somewhere a query can search by similarity. The vector database is that somewhere. At answer time it takes the query vector, returns the nearest chunks, applies whatever filters the request carries (this tenant, this date range, this document type), and hands the survivors to the model.

Everything upstream of it is ingestion, which is where messy PDFs get chunked; fusing dense and sparse results is retrieval design, which our flagship teardown walks through on our matcher; and whether any of it worked is a measurement question, which the golden-set post shows how to test. The database itself decides three things: where the data lives, how far the index scales, and what a filtered query returns. This article is about those three.

Six vector databases on one table

Here is the whole field on one screen, every vendor fact in it checked against its documentation on the date in the table header. The rest of the article is the reasoning behind each row, and the filtering section is where the vendor numbers and the demo charts part ways.

Pinecone: zero ops, if the data can live in a cloud account

Pinecone is the fastest way to a working production index. Serverless, with capacity sized for you; you pay for storage and the reads and writes you make. For a team that wants to ship and stop thinking about the database, it is still hard to beat.

Hybrid search comes three ways in the October 2026 docs. A text-match filter on a full-text field narrows the candidates before a dense search ranks them, in one request on the Documents API. A keyword search and a dense search run separately and merge client-side with reciprocal rank fusion. On the Vectors API, a dense and a sparse vector sit on every record and are queried together; you set the dense-to-sparse balance by scaling the query vectors yourself, and the unbounded sparse scores need normalization.

Two things to know going in. The standard service runs in Pinecone's cloud. Bring Your Own Cloud, an Enterprise-tier feature, moves the data plane (the vectors, the queries, the index storage) into a dedicated VPC in your own AWS, GCP or Azure account, while the control plane that handles index lifecycle, authentication and billing stays with Pinecone. The docs are specific about how tight that tie is: all traffic is outbound from your cluster, an agent pulls operations and reports heartbeats, and once heartbeats are missing for more than 60 minutes billing stops and the deployment is marked disconnected. That is built for data-residency requirements, and the standing outbound link to the control plane rules out an air-gapped site.

The second is the bill. It scales with usage, gently at first and more steeply later, with enough lock-in that moving a large index out becomes a project of its own. Pinecone's own pricing page, read on 30 October 2026, puts Builder at $20 a month flat, Standard at a $50 monthly minimum and Enterprise at a $500 monthly minimum, with usage metered above those two minimums. Pinecone remains the right answer for plenty of teams.

Weaviate: the hybrid and multi-tenant engine

If hybrid search is the product and you want it native, Weaviate is the strongest candidate on this table. A single query string runs a BM25F keyword search and a vector search and fuses the two result sets; the alpha weight tilts it toward either side, and Relative Score Fusion has been the default fusion method since v1.24.

Multi-tenancy is a first-class concept: every tenant gets its own shard, the docs put 50,000 or more active shards on a node, and idle tenants can be parked on local disk or offloaded to cloud storage until they are needed again. It runs self-hosted on Docker or Kubernetes, in Weaviate Cloud, or through the AWS and GCP marketplaces, which keeps a compliance team happy. If our matcher had been a multi-tenant product instead of an internal tool, this is the one I would have looked at first.

Qdrant: speed, filtering, and a small VPS

Qdrant is Apache 2.0, fast, and built around filtered search, which is why we run it. Its Query API, in the server since v1.10, fuses dense, sparse and BM25 full-text results with RRF, or with DBSF since v1.11. The hybrid mechanics, the fusion and the quantization are in the flagship teardown, so this section stays with what the database itself does. It self-hosts on a single small VPS, Qdrant Cloud is there when you want it managed, and Hybrid Cloud runs the databases inside your own Kubernetes cluster with only an outbound connection to Qdrant's console for telemetry and management instructions.

On filtering, Qdrant adds extra HNSW edges at index time for each indexed payload field, so a filtered query still walks a connected graph. Its own article notes that the build skips any value shared by more points than a size cap, sometimes a whole field's worth, and where the edges run out ACORN-1 can be switched on per query to step through neighbors of neighbors. The planner picks the graph, ACORN, a full scan or the payload index on each request.

Our matcher can filter by section type and by person, with a payload index on each field, so the filter rides inside the search. For retrieval quality as the core job, on your own infrastructure, it is the one to beat.

pgvector: the boring answer that is usually right

John Loeber's reply on X to Rak Garg, who was overhearing a vector-database sales rep's call at SFO, scripted the customer's side as "But why wouldn't I just use postgres with pgvector?" and picked up a few hundred likes because it is the right first question.

If you already run Postgres, start with pgvector, a PostgreSQL-licensed extension. Your vectors live next to your application data, you get one backup story and one transaction, and you run one system. Hybrid search is something you compose, a tsvector full-text query and a pgvector query fused with reciprocal rank fusion in SQL, the way Supabase's hybrid-search guide lays it out, and the top-end speed belongs to the purpose-built engines; most projects start small and plain on day one.

The old wisdom was that pgvector fell over around ten million vectors. The limit underneath that figure is memory: an HNSW graph has to sit in RAM to stay fast, so the ceiling moves with the instance size and the vector width. The pgvectorscale extension changed the arithmetic with a disk-friendly DiskANN-style index and statistical binary quantization, and it carries Postgres into the tens of millions of vectors. The pgvectorscale README benchmark (Tiger Data, formerly Timescale, the extension's own vendor) ran 50 million Cohere 768-dimension vectors self-hosted on EC2 against Pinecone's s1 index at 99% recall. That is the vendor's number for the vendor's workload, which is why the table says tens of millions rather than fifty.

The memory cliff is the thing to plan around, more than any row count. In pgvector issue #700 (October 2024) a user benchmarked HNSW on a 32 GB RDS instance with 16 GB of shared buffers and OpenAI 1536-dimension vectors: about 2,110 queries a second at two million vectors, 1,225 at two and a half million, where the 19 GB index first outgrew the 16 GB of buffers, 102 at three million, and 12.9 at five million. The maintainer closed it in March 2025 pointing at disk speed and the non-default m=32 the test used, and listed the usual remedies: the default m=16, half-precision or binary-quantized vectors so more of the data fits in memory, and a memory-optimized instance. The reasons to leave Postgres are now hybrid quality, filtered recall and RAM, rather than a count.

Milvus and Chroma: the two ends

Two more belong on the map, for the extremes. Milvus is built for the billion-vector end, with storage and compute disaggregated so its compute nodes scale sideways. Its docs (v3.0, the current release line) describe three shapes. Milvus Lite is a pip-installed Python library that keeps its data in local storage, for notebooks and prototypes. Standalone packs every component into one Docker image on a single server, and the docs size it by estimating memory from vector dimensions, scalar fields, index settings and replicas, then benchmarking query concurrency and write rate. Distributed runs on Kubernetes, which the docs say can sustain you towards tens of billions of vectors, and is where the operational cost lives.

BM25 full-text search is built in and hybrid_search fuses the dense and sparse requests with an RRF or weighted ranker, so the old line that Milvus means Kubernetes plus a separate keyword engine is out of date. In the same v3.0 docs, filtered search narrows the set to the entities matching the filter before the ANN search runs, with iterative filtering as the alternative when an overly complex expression drives up latency.

Chroma is the other end: Apache 2.0, it runs inside your process and takes you to working search in an afternoon. Its 2026 docs list dense search with full-text contains and regex filters on every deployment; sparse and hybrid search run through the Search API, which the docs place on Chroma Cloud for now, with single-node support planned.

Single-node client-server mode is one command, and Chroma Cloud is the managed, distributed version on object storage for anything past what a single node holds. The self-hosted shape is still a single node, which is the ceiling for a prototyping tool. Most production RAG lands between the two, and knowing they exist stops you from forcing a middle-tier tool to do an end-tier job.

Filtering is where it actually breaks

Almost every benchmark you will read measures the wrong thing. They race raw similarity over a flat dataset: one unfiltered query at a time on an otherwise idle box. Production looks different. Many requests are in flight at once, each asking for a different slice (this tenant, this date range, this document type), and how the engine resolves those metadata filters decides both what comes back and how long it takes. Filtering under concurrency is the part to test, and the numbers below show how far filtered recall can fall before any load is added.

The failure is quiet, and it has numbers now. pgvector's own README states it plainly: with an approximate index the filter is applied after the index is scanned, so if a condition matches 10% of rows, HNSW with the default ef_search of 40 returns about 4 rows on average, a LIMIT 10 query coming back short and reporting success. Starting with 0.8.0 (October 2024) you can switch on iterative index scans, which keep scanning until enough rows pass or a scan limit is reached.

AWS measured the before and after on Aurora, a vendor test on 10 million 384-dimension product vectors: pgvector 0.7.4 returned 10% of the expected results on a category filter and 1% on a complex filter, and 0.8.0 with iterative scans returned 100% on both. Pinecone's own pg_pinecone launch post (October 2026, from a vendor whose new Postgres extension competes with pgvector's index) describes the same mechanism, HNSW post-filtering that can return fewer rows than its LIMIT.

The independent measurement says the same. On recallrun.dev (October 2026) Alby Tomy ran 100,000 vectors through hnswlib: at 1% selectivity, fetching the top 100 and filtering afterwards recalled 0.191, about 1.9 of the 10 results asked for. Filtering inside the graph traversal kept recall at 1.0 but took 17 ms. Reaching 0.884 by over-fetching meant pulling 1,000 candidates at ef 1,000, and for the most selective filters an exact scan over the filtered subset was both fastest and always correct.

Qdrant's ACORN article (August 2026, one engine, the vendor's own benchmark) shows the same shape at a million vectors with ef 64 and a filter keeping 1% of points: a plain HNSW graph scored 0.1% Recall@10, ACORN-1 pulled it back to 67.7%, and filterable HNSW, the extra-edges approach Qdrant builds by default, scored 99.8% at 1.0 ms. Still, it is the clearest picture of why in-graph filtering exists.

Two designs sit behind those numbers. Qdrant folds the filter into the graph for indexed payload fields and hands the narrowest filters to the payload index, so a selective single-field filter stays cheap and keeps its recall, which is the design reason we run it; its own article shows AND filters across two fields are where ACORN has to step in.

A post-filtering engine fetches the nearest neighbors first and discards the ones that miss the filter; when the filter is narrow it discards almost everything and has to widen and retry, which is exactly when tail latency blows up, or it quietly returns four rows. pgvector is in that second group, and since 0.8 its iterative scans, once switched on, widen and retry, up to a scan limit, instead of returning the short list, which is a real part of why the Postgres answer now holds further up the curve.

So when you are down to your last two finalists, skip the demo benchmark. Fire a few hundred concurrent queries carrying the filters your real tenants will use, including one that keeps about one row in a hundred, and record two things: the 99th percentile latency, and how many rows came back against how many you asked for. A result set that is quietly short is the failure that reaches a user, and counting the rows yourself is how you catch it first.

The decision, in the order that matters

Managed or self-host, the axis under all of it

Underneath the names is one tradeoff that repeats. Managed buys you zero operations and the fastest path to production, and charges for it in money and in lock-in. Self-host buys you control and a cheap bill at scale, and charges for it in the hours you spend running it.

One thing skews this today: agents. A human-in-the-loop app reads far more than it writes, but an agent writes constantly, updating memory, pruning context, re-indexing, and usage pricing meters every one of those writes. So an agentic workload can cross the line where a flat self-hosted bill beats usage billing while the corpus is still modest. If you are building agents, model the write volume against the vendor's write pricing before you sign up, while switching is still cheap.

A two-person team racing to a demo should probably pay Pinecone and stop thinking about it. A team with a data-residency clause and an ops engineer already on payroll should self-host Qdrant or Weaviate and keep the money.

Also on the 2026 shortlist

Six engines fit on one table; a few more deserve a look before you commit, each checked against its own docs the same day as the table.

LanceDB ships as an open-source embedded library plus an Enterprise distributed tier on the same Lance format, with vector, full-text and hybrid search and reranking in one library, which suits a team that wants the data in files on object storage rather than in a server.

Turbopuffer is managed only and uses object storage as the sole source of truth with an NVMe and memory cache in front; its docs quote a cold first query at a p50 of 874 ms on a million documents before the namespace is cached, offer BM25 and hybrid search, and run multi-tenant by default, single-tenant, or BYOC.

Elasticsearch and OpenSearch are the answer when you already run one. Elastic recommends hybrid through its retriever syntax with reciprocal rank fusion and the semantic_text workflow, and OpenSearch runs a search pipeline with either a score-based normalization processor or a rank-based RRF processor.

MongoDB Atlas adds $rankFusion and $scoreFusion stages for hybrid search over its vector index, with the RRF rank constant fixed at 60.

Supabase is managed Postgres with pgvector, and its hybrid-search guide is a clean public write-up of tsvector plus pgvector fused with RRF in a single SQL function; its pgvector page carries the same warning as the README, that a naive filter on an HNSW index may return fewer rows than requested.

FAQ

Which vector database is best for RAG? The one that fits your hardest constraint. If the data must stay on hardware you own, self-host Qdrant, Weaviate, Milvus or pgvector. If Postgres already runs the application, start with pgvector. If retrieval quality under selective filters is the product, Qdrant. If you want zero operations and the data may live in a cloud account, Pinecone. Scale alone rarely decides it below the tens of millions.

Is pgvector enough for production RAG? Often, yes. Vectors sit next to your application data with one backup and one transaction, and pgvector 0.8.0 (October 2024) added iterative index scans that, once switched on, keep a filtered query scanning until enough rows pass. With pgvectorscale it carries Postgres into the tens of millions of vectors; the README benchmark (Tiger Data, formerly Timescale, the vendor) ran 50 million. Plan around index RAM before row counts.

Pinecone or Qdrant for RAG? Pinecone when you want a managed index and your data may live in Pinecone's cloud or, with BYOC, in your own AWS, GCP or Azure account. Qdrant when the data must stay on your hardware, when selective metadata filters have to keep their recall, or when a small self-hosted box is the budget. We run Qdrant for our own matcher because of the filtering.

Can Pinecone run on your own hardware? The managed service runs in a cloud: Pinecone's own, or, under Bring Your Own Cloud, a VPC in your AWS, GCP or Azure account with an outbound line to Pinecone's control plane. The exception is pg_pinecone, an Apache 2.0 Postgres extension from October 2026, whose default native engine builds and searches its index entirely inside your Postgres database. For servers you own, Qdrant, Weaviate, Milvus and pgvector self-host.

Chroma or Pinecone for a RAG prototype? Chroma for the prototype: it runs inside your process, is Apache 2.0, and its 2026 docs cover dense search with metadata, full-text and regex filters, so you have working retrieval in an afternoon. Pinecone when the prototype has to become a managed production index with Pinecone running the servers. Chroma Cloud keeps the Chroma API and adds sparse and hybrid search through its Search API.

What are the Pinecone alternatives for RAG? Self-hosted or managed Qdrant, Weaviate and Milvus for a purpose-built engine; pgvector, on your own Postgres or on Supabase, when the data already lives there; Chroma for prototypes and small deployments; Turbopuffer and LanceDB for object-storage designs; and Elasticsearch, OpenSearch or MongoDB Atlas when you already run one and want hybrid search on that same system. Pick by data residency, scale and filtered recall, in that order.

What 2muchcoffee covers

We build production RAG and AI systems, Guidable's audio tours included, and choosing the store is one of the first calls we make with a client, usually in the first conversation, because moving a large index out later becomes a project of its own. Our own work sits on both sides of this table: our matcher, whose code is public and readable, runs on Qdrant, and we built Notesign's retrieval on pgvector.

If you are staring at this fork and unsure which constraint should win, that conversation is where an AI build with us starts, before anyone writes a line of code, and our engineering team is who you would have it with.

One concrete action

Before you compare a single benchmark, write down your two hardest constraints: where the data is allowed to live, and the order of magnitude you are heading toward. Most of the table disappears once those two are on paper. The database you are left with is usually the one to start with.

If two survive and you have to benchmark, benchmark them the way the filtering section said, under concurrent filtered load with rows returned counted, and read any published chart with a cold eye. ann-benchmarks is the independent suite for raw approximate-nearest-neighbor performance; VectorDBBench, which Zilliz (the company behind Milvus) sponsors and says so in its README, adds filtered and concurrent cases. Vendor charts tend to be tuned for the workload that flatters them, and some database licenses carry a DeWitt clause, a term that gives the vendor a veto over published benchmarks, which is one reason independent numbers are so thin.