pgvector vs Qdrant: a benchmark on 100 000 vectors with 1536 dimensions

The "Postgres with an extension or a dedicated vector database" debate usually runs on confident assertions. Machine Learning Mastery proposes replacing them with a measurement: pgvector and Qdrant run in Docker on the same machine, receive the same 100 000 vectors with 1536 dimensions (the size produced by OpenAI text-embedding-3-small) and use identical HNSW index settings. The results come in four metrics: median latency p50, tail latencies p95 and p99, and queries per second.

The debate with no numbers

The typical story goes like this. On Tuesday a team adds pgvector to an already running Postgres. Embeddings sit next to relational data, and a single query both filters and searches for similar items. Six months later, an email arrives from a vendor: it's time to migrate to a "real" vector database before you hit the ceiling. The email contains no benchmark, only confidence.

pgvector is an open-source extension for Postgres, currently at version 0.8.6, and it supports Postgres 13 and newer. It adds a native vector type plus exact and approximate nearest-neighbor search. A vector is stored in the same table as the record it describes, and can even sit in the same row, and you query it with ordinary SQL. There is no separate service, no second data source to keep in sync, and no network hop between the relational and vector parts. It supports single-precision, half-precision, binary and sparse vectors, as well as five distance functions: L2, inner product, cosine, L1 and Hamming.

Five dedicated databases Postgres gets compared with

A dedicated vector database is a separate service with its own process and storage, designed for vector search from the ground up. The cost of that choice is clear: you have to deploy a new system, monitor it, back it up and keep it in sync with the source of truth. The author reviews the five most popular options:

• Pinecone — a fully managed cloud database with no setup, built for enterprise scale with minimal operational effort.
• Qdrant — a high-performance database written in Rust, strong at fast queries with complex filtering on JSON payloads.
• Weaviate — an open-source, AI-oriented system with built-in vectorization and hybrid search with BM25.
• Milvus — a distributed database with GPU acceleration for massive workloads of billions of vectors.
• ChromaDB — a lightweight embedded database for local prototyping and Python development.

For the hands-on comparison the author chose Qdrant. It has the most detailed and methodologically transparent public benchmark against pgvector, and the article builds on that.

How a fair measurement is set up

Postgres 17 with the extension starts from the pgvector/pgvector:pg17 image, and Qdrant starts with a single docker run command on ports 6333 and 6334. Both systems use 1536 dimensions and the cosine metric. The dataset is synthetic: 100 000 vectors drawn from a normal distribution with a fixed seed=42 and normalized to unit length, as real embedding models do. In Qdrant the data is loaded in batches of 1000 points; in Postgres it goes in through the pgvector-python adapter.

The key decision is that the indexes are identical. In pgvector the HNSW index is created with m=16 and ef_construction=64 (its defaults), and in Qdrant the same values are set through HnswConfigDiff. The author states plainly that comparing systems with different index parameters yields two incomparable results. On the query side, hnsw.ef_search is also 64, and the result limit is 10.

Queries run against 200 new vectors that are not in the loaded set. Otherwise, a vector already in the index would find itself at zero distance, and the measurement would be meaningless. Time is measured with perf_counter, latencies are sorted, and p95 and p99 are taken by position in the sorted list. QPS is the number of queries divided by the total run time.

How to apply this yourself

To reproduce the test, you need Docker with Compose, Python 3.10+ and about 8 GB of free memory. No cloud accounts are required.

The practical logic of the choice follows from the architecture itself. If your data already lives in Postgres and a query has to combine a filter on relational fields with similarity search, pgvector spares you a second system and the synchronization. If you need fast filtering on complex JSON fields, Qdrant is a fit. For collections with billions of vectors, consider Milvus; for zero operational overhead, Pinecone; for built-in vectorization and BM25, Weaviate.

One piece of advice beyond the method: random normal vectors lack the cluster structure of real embeddings, and the script measures only latency. Before making a migration decision, run the same test on your own embeddings and add a recall check against exact search.