In this article
The problem
We need a vector database for our RAG pipeline. Options range from managed services (Pinecone, Weaviate Cloud) to integrated solutions (pgvector in our existing PostgreSQL).
What we weighed
Pinecone
Pros
- +Purpose-built, excellent performance at scale
- +Managed — zero operational overhead
- +Serverless is now the default deployment model (pod-based indexes moved to legacy status)
Cons
- −Additional vendor dependency and cost
- −Data leaves our Neon ecosystem
- −Overkill for our current scale (<100K vectors)
pgvector (Neon)
Pros
- +Already in our stack — zero new infrastructure
- +ACID transactions with metadata
- +SQL-based querying (familiar to team)
- +Free tier covers our needs
Cons
- −Performance degrades at millions of vectors
- −Fewer ANN algorithm options than specialised DBs
- −HNSW index tuning requires PostgreSQL expertise
Qdrant
Pros
- +Best open-source performance benchmarks
- +Rich filtering with payload indexes
- +Can self-host or use cloud
Cons
- −Another service to manage
- −Rust-based — team less familiar
What we chose
We chose pgvector via Neon. Our vector count is well within pgvector's sweet spot (<1M vectors). Using our existing PostgreSQL instance eliminates operational complexity, and Neon's built-in vector functions provide a clean API. We'll migrate to a dedicated vector DB if we exceed 1M vectors.
What it committed us to
- •Vector search performance tied to PostgreSQL resources
- •Must create HNSW indexes with appropriate parameters (m=16, ef_construction=64)
- •Cannot use advanced features like multi-vector search without custom SQL
- •Scaling ceiling around 1-5M vectors depending on dimensionality