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

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.

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.

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 concern, but it is a common alternative that Qdrant users ask about.