Should you store your embedding vectors in a PostgreSQL database using the pgvector extension, or entrust this task to a dedicated vector database? A technical guide aims to answer this question with performance measurements rather than theoretical arguments, comparing pgvector to Qdrant.
Two Architectures, One Goal
pgvector is an open-source extension for PostgreSQL, version 0.8.6, compatible with PostgreSQL 13 and later, according to its official GitHub repository. It adds a dedicated column type for vectors, as well as exact and approximate nearest neighbor searches. In practice, an embedding, i.e., the numerical representation of content as a vector, can be stored in the same table as the data it relates to and queried using the usual SQL language. Five distance functions are offered, including cosine and dot product.
A dedicated vector database, conversely, is a separate service with its own storage engine, designed around vector search. The guide notably cites Pinecone, Qdrant, Weaviate, Milvus, and ChromaDB. This architectural choice implies deploying, monitoring, and backing up an additional system and keeping it synchronized with the database containing the reference data.
Local Measurements, Then at Scale
The guide proposes a reproducible test on a laptop, using Docker, Python 3.10 or later, and about 8 GB of free RAM. The dataset is synthetic: 100,000 vectors of 1536 dimensions, the size of a common embedding model, loaded into both systems with the same HNSW index parameters. On such hardware, latencies are, according to the author, between a few milliseconds and a few tens of milliseconds, with significant variations depending on the available CPU and memory. This volume remains too modest to draw a production conclusion.
For this question, the guide relies on a study published by Tiger Data. It covers 50 million Cohere embeddings of 768 dimensions, tested on AWS r6id.4xlarge machines (16 vCPU, 128 GB RAM), using a modified version of the ANN-Benchmarks tool. The guide highlights an important point: the test was conducted with pgvector combined with pgvectorscale, a Timescale extension that adds another index type, StreamingDiskANN, and not with pgvector alone.
According to these results, at a 99% recall, PostgreSQL with pgvectorscale reaches 471.57 queries per second, compared to 41.47 for Qdrant. The median latency is almost identical, at 31.07 ms versus 30.75 ms. Qdrant, however, stands out on extreme latencies: its p99 is 38.71 ms, compared to 74.60 ms, and its index was built in 3.3 hours, compared to 11.1 hours. For the guide, both systems remain under 100 ms at all measured percentiles.
Which Choice Based on Workload
The guide estimates that pgvector is suitable for volumes up to about 5 to 10 million vectors, with moderate query concurrency, and when a team already masters PostgreSQL. It also highlights the transactional consistency between relational data and vectors, which allows updating a document and its vector in the same transaction.
Conversely, a dedicated database is justified, according to the article, for volumes of several hundred million to several billion vectors, or for a strict constraint on extreme latency during highly demanding filtered searches, an area where Qdrant shows the measured advantage. Milvus is cited for GPU-accelerated indexing, and Pinecone for a fully managed service with no internal administration required.
