When would you choose pgvector inside an existing Postgres database over a dedicated vector database like Qdrant?

Question

Accepted Answer

pgvector is the right choice when the vector data is a small part of a larger relational workload and the benefits of keeping everything in one database outweigh the specialized performance of a dedicated vector database. The specific scenarios are: the dataset is small (up to a few million vectors, where pgvector's performance is competitive), the queries need transactional consistency with the relational data, the team already operates Postgres and does not want to add another database, the vector search is not the primary workload, or the application needs joins between vector results and relational tables. In these cases, pgvector avoids the operational overhead of a second database and the complexity of keeping the two in sync. The vector search is slower than Qdrant at scale, but if the dataset is small or the queries are not latency-critical, the difference may be acceptable. The mechanism that makes pgvector work is that it adds a vector column type and index types to Postgres. The vector index is built and queried like any other index, and the vector column is a regular column that can be selected, joined, and filtered. This means the vector search can be part of a SQL query that also filters by relational columns, joins with other tables, and participates in a transaction. The consistency guarantee is the same as any other Postgres operation: a vector insert is visible to a vector search in the same transaction, and a rollback rolls back the vector data. This is not achievable with a separate vector database, where the vector store and the relational store are separate systems that must be kept in sync. The cost is performance: pgvector's indexes are less optimized than Qdrant's for large-scale ANN search, and Postgres is not designed for the memory access patterns of vector search at scale. As the dataset grows, pgvector's latency grows faster than Qdrant's, and at some point the dedicated database becomes necessary. Small scale: up to a few million vectors, where pgvector's performance is competitive. Transactional consistency: vector search must be consistent with recent relational writes. Operational simplicity: the team already operates Postgres and does not want a second database. Joins: vector results need to be joined with relational tables. Feature within a larger app: vector search is not the primary workload. Data volume: large datasets or high QPS favor a dedicated database. Latency: strict p99 SLAs at scale favor a dedicated database. Advanced features: quantization, multivector, hybrid retrieval, and advanced filtering favor Qdrant. The trade-off is between operational simplicity and performance at scale. pgvector is simpler, keeps everything in one database, and provides transactional consistency, but its performance degrades as the dataset grows and its feature set is narrower. Qdrant is faster, more scalable, and richer in features, but adds a second database to operate and requires keeping the vector data in sync with the relational data. The common mistakes are: (1) choosing pgvector for a large dataset because the team already knows Postgres, then discovering that the latency is unacceptable; (2) choosing Qdrant for a small dataset because it is more specialized, then adding operational overhead for no benefit; (3) not considering the consistency implications of a separate vector database; (4) not benchmarking pgvector at the expected scale before committing. Version note: pgvector and Qdrant both evolve, and the performance comparison shifts over time. pgvector's HNSW implementation has improved, and Qdrant has added features. Benchmark on the current versions with your data and query pattern before deciding. # pgvector: vector search inside Postgres, with transactional consistency and joins.

# CREATE EXTENSION vector;
# CREATE TABLE documents (
#     id BIGSERIAL PRIMARY KEY,
#     tenant_id BIGINT NOT NULL,
#     content TEXT,
#     embedding vector(768)
# );
# CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);

# A transactional insert + search:
# BEGIN;
# INSERT INTO documents (tenant_id, content, embedding) VALUES (1, '...', '[...]');
# SELECT id, content FROM documents
#   WHERE tenant_id = 1
#   ORDER BY embedding <=> '[...]'
#   LIMIT 10;
# COMMIT;

# Qdrant: separate database, more scalable, richer features.
from qdrant_client import QdrantClient, models

client = QdrantClient('http://localhost:6333')
client.upsert('documents', points=[models.PointStruct(id=1, vector=[0.0]*768, payload={'tenant_id': 1})])
hits = client.query_points('documents', query=query_vector, limit=10,
    query_filter=models.Filter(must=[models.FieldCondition(key='tenant_id', match=models.MatchValue(value=1))])).points Version-dependent: pgvector's HNSW support and performance have evolved, and Qdrant's feature set has expanded. The comparison should be based on the current versions and benchmarked with the actual data and query pattern. pgvector is not a Qdrant-specific concer

When would you choose pgvector inside an existing Postgres database over a dedicated vector database like Qdrant?

Small scale, transactional consistency, and operational simplicity favor pgvector

When would you choose pgvector inside an existing Postgres database over a dedicated vector database like Qdrant?

Small scale, transactional consistency, and operational simplicity favor pgvector

Scenario Questions

Follow-up Questions