TL;DR: pgvector is an open-source PostgreSQL extension that adds a vector column type, similarity operators, and approximate nearest-neighbor indexes. It turns the database you already run into a capable vector store, which is why "just use pgvector" became the default answer for teams whose data already lives in Postgres.
How it works
After installing the extension, you declare a column such as embedding vector(1024) on an ordinary table, store each chunk's embedding in it, and query with distance operators: nearest neighbors by cosine distance, inner product, or Euclidean distance, expressed as a plain ORDER BY ... LIMIT in SQL. Your chunk text, its metadata, and its vector live in the same row - no second system, no synchronization job.
Exact nearest-neighbor scans get slow as tables grow, so pgvector ships two approximate index types. IVFFlat partitions vectors into clusters and searches only the closest ones - fast to build, cheap on memory, slightly less accurate. HNSW builds a layered graph of vectors - slower to build and hungrier for memory, but with better speed-recall trade-offs at query time. Both trade a little recall for a lot of speed, and both are tunable per query.
The practical advantage is that vector search composes with everything Postgres already does. One SQL statement can combine similarity with a WHERE clause on tenant, date, or permissions; joins pull in related rows; transactions keep vectors consistent with the data they describe; and backups, replication, and monitoring come along for free. Pairing the vector index with Postgres full-text search even yields a self-contained hybrid search setup. Companion extensions such as pgvectorscale push scale and performance further for heavier workloads.
The honest limits: Postgres shares its memory and CPU between vector search and everything else it is doing, and a purpose-built engine can win on very large collections or specialized features. The sensible default is to start with pgvector if you already run Postgres, and reach for a dedicated vector database only when measurements - not vibes - say you have outgrown it.
Where it sits in the AI stack
pgvector occupies the vector-storage slot of the retrieval stack - the same position a dedicated vector database would hold, just inside Postgres:
For a RAG application, that often collapses the data layer to a single database serving both the app and its retrieval.
Key tools and implementations
-
Supabase
A managed Postgres platform that ships pgvector enabled and documents RAG patterns around it.
-
Neon
Serverless Postgres with pgvector support, popular for spin-up-fast prototypes that grow.
-
Amazon RDS and Aurora
Mainstream managed Postgres offerings that include the extension for production workloads.
-
pgvectorscale
A companion extension adding a compressed index type aimed at larger vector workloads.
Related entries
- Vector database A database that stores embeddings and finds nearest neighbors fast, powering semantic search and RAG.
- Semantic search Search that ranks results by meaning, using embeddings, so matches do not require the exact words.
- RAG (retrieval augmented generation) Fetching relevant documents at query time so a language model can answer from your data instead of memory alone.
- Embedding A list of numbers capturing a piece of content's meaning, so similar things sit close together in vector space.