Key takeaways
- pgvector adds vector columns, distance operators and HNSW or IVFFlat indexes to PostgreSQL.
- It is a vector extension rather than a purpose-built database, and it is enough for many RAG apps.
- pgvector runs on CPU with its own index implementations; it does not use GPUs or FAISS.
- Keep one column or table per embedding model, since dimensions and models cannot be mixed.
- Supabase enables pgvector in one click; use SQL functions, HNSW indexes and row level security.
pgvector is an open-source PostgreSQL extension that adds a vector data type, distance operators and approximate nearest neighbour indexes, so you can store embeddings next to your relational data and run semantic search with SQL. I build RAG systems with Python, FastAPI and PostgreSQL, so this page covers why to use pgvector, whether it is a vector database, when you need a dedicated one, GPUs and FAISS, semantic search, mixed dimensions, alternatives inside PostgreSQL, and setting it up on Supabase.
Why use pgvector?
Use pgvector when your application already runs on PostgreSQL: embeddings live beside users, documents and permissions, so you get transactions, joins, backups and access control without operating a second database or syncing data between systems.
It supports HNSW and IVFFlat indexes; cosine, Euclidean, inner product and other distances; half-precision and binary vectors; and filtering with ordinary WHERE clauses. Most managed PostgreSQL services include it, such as Supabase, Neon, Amazon RDS and Aurora, Google Cloud SQL and Azure. For many RAG applications with up to several million vectors, its performance is more than enough, and the operational simplicity of one database is a major advantage for small teams.
What is the pgvector database?
pgvector is not a separate database; it is an extension you enable inside PostgreSQL with CREATE EXTENSION vector. It adds a vector(n) column type for embeddings of n dimensions and operators to compare them.
Also asked as: what is pgvector database
Distance operators include <-> for Euclidean distance, <=> for cosine distance and <#> for negative inner product. A similarity search orders rows by distance to a query vector and limits the results. Indexes accelerate this: HNSW gives strong speed and recall with more memory and slower builds, while IVFFlat builds faster but needs data present before indexing and tuning of lists and probes. It is open source under the PostgreSQL licence.
Is pgvector a vector database?
Functionally, PostgreSQL with pgvector acts as a vector database: it stores embeddings, indexes them and answers similarity queries. Strictly, it is a general relational database with a vector extension, not a purpose-built vector database.
The distinction matters for features and scale. Purpose-built vector databases offer things like advanced quantization, built-in hybrid fusion, multi-tenant vector partitioning and horizontal sharding designed for billions of vectors. pgvector offers the full power of SQL and PostgreSQL's maturity, plus vector search good enough for most applications. Many teams describe their PostgreSQL with pgvector as their vector store, which is accurate for practical purposes, especially in RAG systems of moderate size.
Do you really need a vector database, or is pgvector enough?
For many applications, pgvector is enough, especially when you already use PostgreSQL and have up to a few million vectors. Choose a dedicated vector database when scale, latency targets, heavy filtering or advanced features exceed what PostgreSQL handles comfortably.
Also asked as: do you really need a vector database? pgvector vs dedicated
Signs you may need a dedicated system: hundreds of millions of vectors, very high query rates, strict low-latency requirements under heavy filtering, many tenants with separate indexes, or a need for features such as built-in sparse vectors and rescoring. Before switching, tune pgvector: use HNSW, raise ef_search, add B-tree indexes for filters, use iterative index scans in newer versions, and size memory so indexes fit. Measure with your real queries before deciding.
Does pgvector use a GPU?
No. pgvector runs on the CPU inside PostgreSQL. Index building and searches use CPU and memory, with SIMD instructions to speed up distance calculations, and newer versions can build HNSW indexes in parallel across CPU cores.
Also asked as: does pgvector use gpu
GPUs matter elsewhere in your pipeline: generating embeddings with an embedding model is the GPU-heavy step, and some dedicated vector systems, such as FAISS on GPU, accelerate search with GPUs at very large scale. For typical pgvector workloads, more RAM so the index fits in memory, fast storage and enough CPU cores have a bigger effect than any GPU. Raise maintenance_work_mem and use parallel workers to speed up index builds.
Does pgvector use FAISS?
No. pgvector has its own implementations of HNSW and IVFFlat written in C inside PostgreSQL. It does not depend on FAISS, although the algorithms are similar in concept to those found in FAISS and hnswlib.
This independence means indexes are stored as normal PostgreSQL index structures, benefit from write-ahead logging, crash recovery and replication, and stay consistent with your table data through transactions. FAISS, in contrast, is a library that keeps indexes in application memory or files you manage yourself. If you prototype with FAISS and later move to pgvector, recall and latency may differ slightly, so re-run your retrieval evaluation after migrating.
Does pgvector support semantic search?
Yes. Store embeddings from any embedding model in a vector column, embed the user's query with the same model, and order rows by cosine distance to find passages with similar meaning. That is semantic search.
pgvector does not create embeddings itself; your application or a database extension calls an embedding model. Combine semantic search with PostgreSQL's full-text search using tsvector and ts_rank, then merge results with reciprocal rank fusion in SQL or application code to get hybrid retrieval, which handles exact terms better. Add filters for permissions, language or document type in the same query. This makes PostgreSQL a capable foundation for RAG systems built with FastAPI or Next.js.
How do you handle different vector dimensions in pgvector?
A vector column has a fixed dimension, and vectors from different embedding models cannot be compared anyway. Use a separate column or table per model and dimension, and always search with a query embedded by the same model.
Also asked as: how to deal with different vector-dimensions for embeddings and search with pgvector
Common patterns: an embeddings table with model name, dimension and a separate column per model; or one table per model, each with its own HNSW index. An unconstrained vector column can hold mixed dimensions, but indexes require a fixed size, so you can use expression or partial indexes filtered by model. When migrating models, add the new column, backfill embeddings, build its index, compare retrieval quality, then switch queries and drop the old column.
Are there more efficient ways to do vector search in PostgreSQL than pgvector?
Yes, several extensions build on or compete with pgvector. pgvectorscale from Timescale adds a StreamingDiskANN index and statistical binary quantization for large datasets, and VectorChord offers fast indexing with quantization, aimed at very large collections.
Also asked as: is there any other more efficient way to perform vector similarity search within postgresql besides pgvector
Other options have included Lantern and Neon's pg_embedding, the latter now deprecated in favour of pgvector. Before adding extensions, tune pgvector itself: use HNSW with suitable m and ef_construction, half-precision vectors to cut memory, binary quantization with re-ranking, and iterative scans for filtered queries. Check that your managed PostgreSQL provider supports the extension you choose, since many only allow a fixed list. Benchmark with your data, filters and hardware before committing.
How do you use pgvector in Supabase?
Enable it in the Supabase dashboard under Database, Extensions, by turning on vector, or run create extension vector; in the SQL editor. Then create a table with a vector column sized for your embedding model.
Also asked as: supabase pgvector tutorial
Next, write a SQL function that takes a query embedding and returns the closest rows, for example ordered by cosine distance with a match threshold and count, and call it from your app through Supabase's RPC interface. Add an HNSW index for speed. Generate embeddings in an Edge Function or your backend, and store them with the text and metadata. Use row level security so users only retrieve documents they may access, which matters for multi-user RAG.





