In this article
Context
We need a vector database for our RAG pipeline. Options range from managed services (Pinecone, Weaviate Cloud) to integrated solutions (pgvector in our existing Supabase PostgreSQL).
Options Evaluated
Pinecone
Pros
- +Purpose-built, excellent performance at scale
- +Managed — zero operational overhead
- +Serverless pricing available
Cons
- −Additional vendor dependency and cost
- −Data leaves our Supabase ecosystem
- −Overkill for our current scale (<100K vectors)
pgvector (Supabase)
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
Decision
We chose pgvector via Supabase. Our vector count is well within pgvector's sweet spot (<1M vectors). Using our existing PostgreSQL instance eliminates operational complexity, and Supabase's built-in vector functions provide a clean API. We'll migrate to a dedicated vector DB if we exceed 1M vectors.
Consequences
- •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
Related Articles
designing rag systems that actually scale