pgvector vs Pinecone vs Weaviate vs Qdrant: Where the Index Sits Decides Everything

At a glance

Four vector stores, four answers to the same question — what does the index sit next to, and what do you have to operate to keep it there. The table lists the basics; the matrix below it shows where each one leans hardest across the axes that actually differ.

Snapshot: 2026-06-01. Vector-store features move quickly; verify against current docs.

pgvector — deep dive

Storage and index model

pgvector is a Postgres extension. You add a column of type vector(d) to an existing table, and the embeddings live on the same row as the rest of your data — same primary key, same foreign keys, same transaction log. The ANN index is one of two shapes: HNSW, a navigable small-world graph kept in shared buffers, or IVFFlat, which clusters the vectors into lists and scans a configurable number of nearest lists at query time. Either way, the index file is a normal Postgres relation; backups, replicas, and point-in-time recovery work without anything new. This is the same vector-search machinery covered in the chunking and vector search primer, but located inside the database that already authoritatively answers "what is this row?".

Query path (vector + filter + hybrid)

Queries are plain SQL. ORDER BY embedding <=> $1 LIMIT k runs the ANN index; a WHERE clause on scalar columns goes through the existing B-tree or GIN index; and the Postgres planner decides whether to filter first and then ANN-search the survivors, or ANN-search and then filter. Hybrid search composes from existing parts: Postgres full-text search (tsvector + ts_rank) joined to the same row that holds the vector, with rank fusion done in SQL — the pattern is the same one in hybrid search and reranking, but written as one query instead of two services. Because the join target is the row itself, agentic queries that need a vector match and the actual business fields ("title, body, author name, last updated") return in one round-trip.

What the runtime makes hard

Two things. First, filtered ANN at very large scale is a known sharp edge — the planner can sometimes pick a strategy that defeats the HNSW index's pruning, and at billions of vectors with high-cardinality filters you may have to coach it with index hints or partition tables. Second, write amplification: HNSW index build and incremental rebuilds tax the same Postgres instance that serves your transactional workload, so heavy ingestion competes for I/O and CPU with the OLTP path. The pragmatic move is to put pgvector on a read replica (or a dedicated logical-replicated copy) when ingest volume gets serious, which is more or less the same playbook you would already run for any read-heavy Postgres workload.

Pinecone — deep dive

Storage and index model

Pinecone is a vector database as a service. You create an index with a name, a dimension, a distance metric, and a region; you partition it into namespaces for tenant or collection isolation; you upsert { id, values, metadata } records over HTTPS. The current serverless tier separates hot compute from a blob-storage cold tier, so the storage you pay for is decoupled from query throughput — there are no shards to size, no replicas to provision, no HNSW parameters to tune. The internal index and ANN algorithm are not part of the contract; Pinecone owns the implementation, and you trade transparency for never having to think about it.

Query path (vector + filter + hybrid)

Queries are an HTTPS POST: vector, top-k, optional metadata filter, optional namespace. Metadata filters are applied during traversal rather than after, so a high-cardinality filter still returns roughly the right top-k. Pinecone supports sparse-dense hybrid by accepting a sparse vector alongside the dense one and fusing the scores; if you want BM25-style lexical search you compute the sparse vector yourself (BM25, SPLADE, or similar) and pass both. The query returns IDs and scores plus the metadata you stored at upsert time — but the full row of business data still lives in your primary DB, so the agent then issues a second query to your Postgres or Mongo to enrich the results.

What the runtime makes hard

Three things. First, two systems of record: every row written to your primary DB has to be embedded, upserted, and kept consistent with Pinecone, so a stale-vector or missing-vector bug is a class of problem you did not have before. Second, vendor lock-in by definition — the service is not self-hostable, so the cheapest hedge is a clean abstraction layer over reads and writes. Third, data boundary: vectors and their attached metadata leave your infra, so regulated content needs an enterprise-region or BYOC plan, and an outage in Pinecone is an outage in your retrieval path. The service is fast to start with and easy to operate; the operating cost is the discipline to treat it as a remote dependency rather than a database you own.

Weaviate — deep dive

Storage and index model

Weaviate is an open-source vector engine with a schema layer baked into it. You declare classes with typed properties, including cross-references between classes — so Article references Author and Topic, the way a graph database does, and each class gets its own HNSW index over a class-level embedding. Vectorization happens server-side via modules: text2vec-openai, text2vec-cohere, text2vec-transformers, plus rerankers and a generative module that can run RAG-in-DB. The architecture is the closest of the four to a small graph RAG system in a box — vectors and typed relationships in one place.

Query path (vector + filter + hybrid)

The default query language is GraphQL. A Get { Article(nearVector: …, where: …) { _additional { distance } author { name } } } returns the vector match, the score, and joined cross-referenced objects in one round-trip. Hybrid search is a first-class operator: hybrid(query, alpha) blends BM25 with vector results, with the alpha parameter controlling fusion weight, and the reranker module can apply a cross-encoder pass at query time. Multi-tenancy is per-class — each tenant gets an isolated HNSW graph, which keeps tenants from polluting each other's recall at the cost of more graphs to maintain.

What the runtime makes hard

Schema evolution is the sharp edge. The schema is a contract — adding a property is fine, but changing a vectorizer, retypeing a property, or restructuring cross-references usually means a re-vectorize and a migration, which is exactly the work pgvector lets you skip by piggy-backing on whatever the application schema already is. Weaviate is also another stateful service in your topology — a separate failure domain with its own backup story, version upgrades, and module configuration. The trade is real: you get RAG-relevant primitives (vectorize, rerank, graph traversal) inside the database, but you operate one more system whose schema you have to keep honest.

Qdrant — deep dive

Storage and index model

Qdrant is an open-source vector engine written in Rust. Data is organized into collections, each of which has a vector size, a distance metric, and optional named multi-vector slots (for example one slot for a dense embedding, one for ColBERT-style late-interaction vectors). Each item is a point: an ID, one or more vectors, and a payload — arbitrary structured JSON, with per-field payload indexes that act like an inverted index on the metadata. The index of interest is HNSW, but Qdrant offers quantization — scalar, product, or binary — that shrinks the in-memory vector footprint by 4× to 32× and rescours the survivors with the full vectors, which is what lets a single node hold a lot of points.

Query path (vector + filter + hybrid)

The signature feature is filter-aware HNSW: the graph traversal evaluates payload filters as it walks, rather than ANN-searching first and discarding non-matches afterwards. The win is recall under heavy filters — the failure mode where a post-filter ANN query returns "I found nothing matching tenant_id=42 in the nearest 200, sorry" mostly does not happen here, because the traversal does not waste its budget on non-matching neighbors. Hybrid search is supported through sparse vectors plus dense (BM25-style sparse vectors fused with dense at query time), and the API exposes recommend, batch search, and scroll alongside plain search, which composes well into agentic retrieval loops where the agent issues repeated, scoped queries.

What the runtime makes hard

You self-host (or use Qdrant Cloud), which means you run another stateful service with its own sharding, replication factor, WAL, and snapshots. Quantization is powerful but not free — you choose the quantization level, rescore depth, and shard count yourself, so the operating overhead is "another distributed database to operate," not "an extension on the database you already have." The payload model is JSON rather than a schema, so there is no equivalent of Weaviate's typed cross-references; relationships are something the application reconstitutes. The honest position: Qdrant gives you the strongest filtered-ANN engine in this set, and the price is a separate stateful system you operate.

Cross-cutting comparison

Where the index sits relative to your primary data

This is the axis the feature lists hide, and it is the one that decides which store survives contact with a production agent. pgvector puts the index on the same rows as your primary data, under the same planner and transaction log, so a single SQL query can join "nearest vector" to "actual business fields" without a second hop. Pinecone moves the index to a managed cloud, which makes operations easy but turns every retrieval into a cross-system join: vectors there, source rows here, and the application is responsible for keeping the two consistent. Weaviate is something stranger — its schema layer wants to be a source of truth (classes, cross-references, server-side vectorization), which is wonderful when the application happens to fit Weaviate's shape, and exhausting when the application's domain schema and Weaviate's schema start to drift. Qdrant takes the most modest position: it is a vector index next door, the payload is opaque JSON, and you join in the application — but the engine is built for that exact shape and does it well.

Filtered ANN behavior at scale

Agentic RAG queries are almost never "give me the nearest k vectors with no filter" — they are "the nearest k vectors that belong to this tenant, this document type, this date range." pgvector defers the strategy to the Postgres planner: at modest scale it picks the right combination of B-tree and HNSW, but at high cardinality you can land on a plan that defeats the ANN index's pruning, and the fix is index tuning or partitioning. Pinecone and Weaviate both filter during traversal, which mostly works; Pinecone hides the algorithm and asks you to trust it, Weaviate exposes inverted indexes per class and gives you a flat-search escape hatch when recall matters more than latency. Qdrant takes filter-aware ANN as its design point: the HNSW traversal evaluates payload conditions as it walks, so the recall-under-heavy-filters failure mode that hurts the other three is, by construction, the case Qdrant tunes for. If your agent's filters are wide and shallow, all four are fine; if they are narrow and selective ("only this customer's docs from the last 30 days, only invoice category"), Qdrant's behavior is the most predictable.

Operations and deployment story

The four split cleanly. pgvector adds zero new operational surface — your existing Postgres backups, replicas, monitoring, RLS, and cloud-DB managed services (RDS, Neon, Supabase, Aurora) cover it, which is the single biggest reason teams that start with pgvector mostly stay there. Pinecone moves the entire operational surface to the vendor: no servers, no shard sizing, no HNSW tuning, in exchange for a remote dependency in your retrieval critical path and a separate billing line. Weaviate is the heaviest of the four to operate — it is its own stateful service, with version upgrades, module configuration, and schema migrations that have no analog in your application database. Qdrant is lighter than Weaviate but still a separate stateful service: a single Rust binary scales from one Docker container to a sharded cluster, but the sharding, replication factor, and quantization choices are yours. Counterintuitively the question "should we operate fewer systems or more capable ones?" answers itself for most teams: fewer systems wins until a query pattern (massive scale, very heavy filters, multi-region) actively forces a more capable one.

When to pick which

Further reading

On this wiki:

• Retrieval-augmented generation (RAG) explained — the retrieve→augment→generate loop the vector store sits beneath, and why retrieval and generation are debugged as two separate halves.
• Chunking & vector search intuition — what an embedding actually is, what nearest-neighbour search does, and how hybrid + reranking layer on top.
• Embeddings: meaning as geometry — why the same vectors work across any of these stores, and what the model (not the index) actually owns.
• Choosing a vector database — a constraint-first selection guide with the ANN / filter / freshness / hybrid / ops axes that genuinely differ between products.
• Hybrid search and reranking — why one retriever is structurally not enough and how to combine BM25, dense, and a cross-encoder pass.
• Agentic retrieval: search as a tool — the loop these stores end up backing when an agent calls retrieval iteratively rather than once.

Project sources:

• pgvector repo — the extension, with HNSW and IVFFlat index docs.
• Pinecone docs — serverless indexes, namespaces, sparse-dense hybrid, metadata filters.
• Weaviate docs — schema, modules, GraphQL query API, hybrid search.
• Qdrant docs — collections, points, payload indexes, filter-aware HNSW, quantization.