The Open-Source AI Stack
RSS

The Stack · Retrieval and Memory · Open source

pgvector

Vector similarity search inside PostgreSQL; lets existing Postgres deployments add RAG without a separate database.

PostgreSQL · stable · Project site → · GitHub →

pgvector is a PostgreSQL extension by Andrew Kane that adds vector data types and similarity-search operators to standard Postgres. Released under the PostgreSQL license. Once installed, you can store vectors alongside any other data in your tables, query them with HNSW or IVFFlat indexes, and combine vector search with normal SQL filters in one query. pgvector matters because most teams deploying RAG do not need a dedicated vector database; they need vector search bolted onto the database they already run. Compared to siblings: Pinecone (closed managed service, fast, no self-host), Qdrant / Weaviate / Milvus / Chroma (purpose-built open vector DBs, more features and better at billion-scale), LanceDB (Lakehouse-style, columnar storage). pgvector's distinctive angle is "you already run Postgres; the vector store is one extension and one ALTER TABLE away." The boring-tech path. Production-ready and widely deployed in 2026. AWS RDS, Supabase, Neon, and most managed Postgres providers ship pgvector pre-installed. For workloads under ~10M vectors with mixed filter-and-search queries, pgvector is the default recommendation. The strategic question: as model context windows grow (1M+ tokens) and as vector DBs add filtering sophistication, the line between "use Postgres + pgvector" and "use a dedicated vector DB" keeps moving. pgvector keeps winning the small-to-medium case.

Sources

Want a follow-up? Ask the chat about pgvector in context. It will compare to siblings at the same layer and ground every claim in the wiki.

Other projects at the Retrieval and Memory layer

8 siblings · ordered open first