pgvector vs Qdrant vs Weaviate (and Milvus) Compared

pgvector vs Qdrant comes down to this: pgvector adds vector search to the Postgres database you already have, while Qdrant (like Weaviate and Milvus) is a separate engine built only for vectors, with more search features and more ways to scale. If your vectors belong to rows in your app and must follow the same permissions, pgvector is usually the simpler and safer choice. If vector search is a large, separate workload, or you need features like built-in hybrid fusion, aggressive quantization or distributed indexes, a dedicated engine earns its place. This comparison goes through the differences one dimension at a time, then gives a pick for three typical teams.

All four are open source, so this is not a "managed vs open" comparison. It is "inside your database vs next to it".

#pgvector vs Qdrant vs Weaviate vs Milvus: summary

Facts for Qdrant, Weaviate and Milvus come from their official docs and pricing pages as of November 2026. Index lists are not exhaustive.

#Data model

pgvector stores a vector as a column. A chunk is a row with its text, its owner, its document id and its embedding. Anything you can say in SQL applies: foreign keys, on delete cascade, check constraints, triggers.

Qdrant stores points: an id, one or more named vectors (of different sizes if you like) and a JSON payload. It also supports sparse vectors and multivectors (several same-shaped vectors per point, scored with max_sim), which matters for late-interaction models.

Weaviate stores objects in collections, with typed properties and one or more vectors. It can vectorize objects on import through integrations with providers such as OpenAI, Cohere, Google, Mistral and Voyage AI.

Milvus stores entities in collections with a schema of scalar and vector fields, including float16, bfloat16, int8, binary and sparse vectors.

The practical difference: in pgvector the vector is part of your application data. In the other three, it is a copy of some of it, plus whatever metadata you chose to send along.

#Filtering

This is where RAG and search apps live or die, because real queries always have a "where".

In pgvector, filters are SQL, so they can be anything: a join to a permissions table, a date range, a subquery. Approximate indexes apply filters after the index returns candidates, which used to mean selective filters returned too few rows. pgvector 0.8.0 added iterative index scans to fix that:

set hnsw.iterative_scan = relaxed_order;
set hnsw.max_scan_tuples = 40000;   -- how far it may keep scanning (default 20,000)

Qdrant filters on payload fields and builds payload indexes so filtered search stays fast. Filtering is one of the engine's main design points. Weaviate and Milvus filter on properties and scalar fields alongside the vector search.

If your filters are simple metadata (tenant, language, date), all four handle them. If your filters are relational ("documents shared with any team this user belongs to"), only Postgres can express them without copying that relationship into metadata.

#Hybrid search

Weaviate has the most complete built-in story: one hybrid query runs BM25F and vector search and fuses the results, with alpha from 0 (keyword only) to 1 (vector only) and relative score fusion as the default since v1.24.

Qdrant and Milvus support sparse vectors next to dense ones, so you can run both kinds of search and combine them.

pgvector has no hybrid feature of its own, but Postgres has full-text search, so you write it: a tsvector column with a GIN index plus a vector query, merged with reciprocal rank fusion. The full function is in Best vector database for RAG. It takes 30 lines of SQL and runs in one round trip.

#Memory and compression

Vector indexes are memory-hungry, so compression decides how much you can serve per server.

Qdrant documents scalar quantization (4x smaller), binary quantization (up to 32x) and product quantization (up to 64x). Milvus has quantized index types such as IVF_SQ8, IVF_PQ and HNSW_SQ. Weaviate also offers compression options.

pgvector has two tools. halfvec stores each dimension in 2 bytes instead of 4. Binary quantization indexes a bit-per-dimension version and re-ranks with the full vectors:

set search_path = public, extensions;

create index on items using hnsw ((binary_quantize(embedding)::bit(1536)) bit_hamming_ops);

select * from (
  select * from items
  order by binary_quantize(embedding)::bit(1536) <~> binary_quantize($1::vector)
  limit 40
) candidates
order by embedding <=> $1::vector
limit 10;

Here $1 is the query embedding your app passes as a parameter. The inner query uses the small bit index to get 40 candidates fast; the outer query orders those by exact cosine distance. It works, but you write and tune it yourself, while the dedicated engines make quantization a collection setting.

#Multi-tenancy

Qdrant recommends one shared collection with a tenant field in the payload and a keyword index on it with is_tenant: true, which keeps each tenant's vectors stored together. Weaviate has native multi-tenancy where each tenant is a separate shard, and tenants can be set to inactive or offloaded to cloud storage to save resources. Milvus uses partitions and filters.

pgvector inherits Postgres: a tenant_id or user_id column, an index that includes it, and a Row Level Security policy so no query can forget the filter. For a SaaS app, that is hard to beat, because it is the same isolation that already protects the rest of your tables. See Multi-tenant Postgres for SaaS.

#Scaling and operations

• pgvector scales with your Postgres server: more memory, read replicas for read-heavy search, partitioning for very large tables. You run one system. The ceiling is one primary server's resources.
• Qdrant runs as a single binary and scales out with sharding and replication in a cluster.
• Weaviate runs as a server or cluster and has a managed cloud.
• Milvus has the widest range: Milvus Lite as a Python library for notebooks, Standalone on one machine, and Distributed on Kubernetes with separate ingestion and search nodes for the largest workloads.

#Hosting and price (as of November 2026)

• Qdrant Cloud: free single-node cluster (0.5 vCPU, 1 GB RAM, 4 GB disk); paid tiers are usage-based (pricing).
• Weaviate Cloud: free tier with 100,000 objects; Flex from $45/month; Premium from $400/month (pricing).
• Zilliz Cloud (managed Milvus): free tier with 5 GB and up to 5 collections; Standard dedicated from $126/month (pricing).
• pgvector: no separate bill. You pay for the Postgres database it runs in.

#Three teams, three picks

A B2B SaaS adding "ask your documents". Tens of thousands to a few million chunks, strict per-workspace permissions, documents edited all the time. Pick pgvector. Permissions and deletes are already solved in Postgres, and one database means one backup and one restore point.

A search product with heavy, spiky query load and collections of tens or hundreds of millions of vectors. Pick Qdrant or Milvus. You get quantization, sharding and a query engine that does nothing else. Choose Qdrant for its simpler operations and filtering, Milvus if you need GPU or disk-based indexes at very large scale.

A team that wants hybrid search and embedding generation with minimal code. Pick Weaviate. Built-in fusion and vectorizer integrations remove most of the glue code.

It is also fine to start with pgvector and move one workload to a dedicated engine later. Vectors are just arrays of floats; exporting them is a select.

#pgvector on StitchDB

StitchDB is a hosted Postgres backend where each project has its own database, with Auth, a REST API and Edge Functions alongside. vector is one of the available extensions:

1. In Studio, open Database → Extensions and switch on vector (it goes into the extensions schema).
2. Create your table with an extensions.vector(1536) column, enable Row Level Security and add a policy (RLS docs).
3. Add an HNSW index and a match function, then call it from any SDK with rpc. The pgvector guide has the complete code.

Check the installed version with select extversion from pg_extension where extname = 'vector' to see which features (iterative scans need 0.8.0) you have.

Trade-offs: StitchDB is EU-hosted only (Germany and Finland), and it runs Postgres, so you get pgvector's ceiling, not a distributed vector engine's. For heavy workloads, Scale and Enterprise projects can run on a dedicated server.

#FAQ

#Is Qdrant faster than pgvector?

Qdrant is built only for vector search and has more tuning options, so on large collections it can be faster. For a few million vectors with an index in memory, pgvector is fast enough for most apps. Benchmark on your own data.

#Is Weaviate better than pgvector for hybrid search?

It is more convenient: hybrid search is one query with an alpha weight. In Postgres you write the fusion yourself, which takes more work but gives you full control and RLS on the results.

#When should I use Milvus?

When you plan for very large collections, need GPU or disk-based indexes, or want a distributed deployment on Kubernetes. For small and medium apps it is more infrastructure than you need.

#Can I self-host all of them?

Yes. pgvector runs in any Postgres you can install extensions on, and Qdrant, Weaviate and Milvus all publish open-source servers.

Start with vectors in Postgres: enable vector under extensions and create a free project.