pgvector

• CategoryEmbedded
• EngineC / Postgres extension
• PricingOpen source
• LicensePostgreSQL License
• Created2021
• GitHub stars13.5k
• Hybrid searchNative
• Edge-readyNo
• Multi-tenantNative
• Max dimensions16,000

pgvector is a Postgres extension that adds vector similarity search to standard Postgres. Cosine, L2, and inner-product distance, HNSW + IVFFlat indexes, exact and approximate search. Runs anywhere Postgres runs (Supabase, Neon, RDS, Aurora, your laptop). The default vector store for the Postgres-aligned half of the AI ecosystem.

• RAG apps already running on Postgres / Supabase
• Workloads under 50 million vectors where horizontal sharding is not yet the constraint
• Teams that want vector + relational data in one query (vector + JOIN)
• Cost-sensitive deployments — the bill is whatever Postgres costs

Skip pgvector for genuinely massive vector workloads (>100M vectors, sub-50ms p99 latency at high concurrency) — purpose-built engines like Pinecone or Qdrant pull ahead. Skip if your stack does not already involve Postgres.

pgvector is the answer most RAG apps should reach for first in 2026. The "do I need a separate vector DB?" question almost always resolves to "no, pgvector is fine" until the workload genuinely outgrows it. Single source of truth, no sync, lower bill.

• Official homepage →
• GitHub repo →

The 30-min call is where your vector-DB choice becomes a real RAG architecture, a chunking + reranking strategy that actually works for your corpus, and a price range you can take to your stakeholders. Describe your data shape, your query patterns, your latency budget. I tell you whether pgvector is genuinely your fit.