pgvector
PostgreSQL vector similarity search, HNSW indexing, embedding storage, and hybrid relational-vector queries.
1 / Vector Search Inside PostgreSQL
pgvector allowed me to store Vector Embeddings directly alongside relational domain data in PostgreSQL, eliminating the need for a separate vector database. For projects that already relied on PostgreSQL for transactional data, pgvector turned the existing database into a combined relational-vector store.
2 / Where I Used It
In Phoenix, pgvector stored document embeddings generated by SentenceTransformers. HNSW indexes on vector columns provided fast approximate nearest neighbor searches for the Hybrid RAG pipeline's dense retrieval stage. Queries combined traditional relational filtering (document metadata, access controls) with vector cosine distance operators in a single SQL statement.
In StudyLink, pgvector enabled Semantic Search across educational notes and course materials. Students could search by meaning rather than exact keywords, and the results were filtered by course enrollment and access roles.
3 / Indexing Strategy
The choice between IVFFlat and HNSW indexes was a practical engineering decision. HNSW provided better recall at the cost of higher memory usage and slower index builds. For the dataset sizes in my projects, HNSW was the clear choice — the datasets fit comfortably in memory, and recall quality directly affected retrieval pipeline accuracy.
4 / Trade-offs
pgvector is excellent for applications where vector search is one capability alongside relational data management. For applications where vector search is the primary workload at massive scale, dedicated vector databases offer specialized optimizations that pgvector does not match. My use cases — thousands to tens of thousands of documents with hybrid relational-vector queries — sit squarely in pgvector's sweet spot.