Key takeaways
- pgvector is a PostgreSQL extension that adds vector columns, distance operators and HNSW and IVFFlat indexes.
- It powers semantic search, RAG, recommendations and deduplication inside an existing Postgres database.
- It is production ready for many workloads, scaling to millions of vectors with good indexing and hardware.
- IVFFlat clusters vectors into lists and searches the nearest lists; HNSW usually gives better speed and recall.
- Indexes go unused when queries do not order by distance with a matching operator and LIMIT, or when tables are small.
pgvector is an open-source extension that makes PostgreSQL a vector database: it adds a vector column type, distance operators for cosine, Euclidean and inner product, and approximate nearest-neighbour indexes, HNSW and IVFFlat, so you can run similarity search with ordinary SQL next to your relational data. PostgreSQL is central to my stack, so this page explains what pgvector means and how it works, uses and history, comparison with Elasticsearch, scaling and production readiness, IVFFlat indexes, why indexes go unused, and enabling it in pgAdmin.
What does pgvector mean?
pgvector is short for "PostgreSQL vector": "pg" is the common abbreviation for PostgreSQL, and "vector" refers to the numerical vectors, usually AI embeddings, the extension stores and searches.
Practically, it means you can add a column like embedding vector(768) to a table and query for the rows most similar to a given vector. It turns Postgres into a combined relational and vector database, so applications such as RAG systems can keep documents, metadata, users, permissions and embeddings in one place, with transactions and backups covering everything.
How does pgvector work?
pgvector stores vectors in table columns and adds operators that compute distances: <-> for Euclidean, <=> for cosine and <#> for negative inner product. Queries order rows by distance to a query vector and take the top results; indexes speed this up by searching approximately.
Without an index, Postgres compares the query with every row, which is exact but slow for large tables. HNSW indexes build a graph of nearest neighbours and walk it towards the query; IVFFlat indexes cluster vectors and search only nearby clusters. Postgres's planner decides when to use the index, and normal features, such as WHERE filters, joins and row-level security, combine with vector search.
What is pgvector used for?
pgvector is used for semantic search, retrieval-augmented generation, recommendations, duplicate and near-duplicate detection, image and face similarity search, and clustering, all within PostgreSQL rather than a separate vector database.
Teams choose it when they already run Postgres and want simpler architecture: one database to back up, secure and operate. A RAG app might store chunks with their embeddings, document metadata and access rules in the same tables, then combine vector search with Postgres full-text search for hybrid retrieval. FaceVision-style systems can store face embeddings with user records, protected by the same database controls.
When was pgvector created?
pgvector was created by Andrew Kane and first released in 2021. It grew rapidly in popularity from 2023, when RAG applications made vector search a mainstream need, and gained HNSW indexes in version 0.5.0 that year.
Since then, releases have added half-precision and binary vectors, sparse vectors, parallel index builds, iterative index scans for filtered queries and many performance improvements. Major cloud providers now offer pgvector on managed Postgres services. Because features differ between versions, check which version your database runs, especially on managed platforms.
pgvector vs Elasticsearch: which should I use?
Use pgvector when your data already lives in PostgreSQL and you want vector search alongside relational queries, transactions and simple operations. Use Elasticsearch when you need advanced full-text search, analytics and aggregations at large scale, with vector search as an addition.
Elasticsearch has richer text analysis, language analysers and distributed search features, but adds another system to operate and keep in sync with your database. pgvector keeps everything in one place, and Postgres full-text search covers basic keyword needs; extensions add BM25 if required. For many RAG applications with up to a few million chunks, pgvector is simpler and sufficient.
Is pgvector scalable?
Yes, for many workloads. With HNSW indexes, enough memory and tuning, pgvector handles millions to tens of millions of vectors with low latency. Beyond that, partitioning, read replicas, quantisation with half-precision vectors, and careful hardware sizing extend its range.
Limits appear with very large collections, very high query rates, or heavy filtering combined with vector search, where specialised vector databases may perform better. Plan capacity by estimating memory for vectors and indexes, testing query latency at your target scale, and monitoring. Many teams start with pgvector and only move vector workloads elsewhere if measurements demand it.
Is pgvector production ready?
Yes. pgvector is widely used in production by companies of all sizes and is supported on major managed Postgres services. It benefits from PostgreSQL's mature reliability features: write-ahead logging, replication, backups, point-in-time recovery and access control.
Production practices: use HNSW indexes for most workloads, build indexes after bulk loads with enough maintenance memory, monitor query plans and latency, keep pgvector updated, and test recall against exact search on a sample. Combine with connection pooling for many concurrent clients. As with any database, load testing at expected scale before launch avoids surprises.
What are IVFFlat indexes in pgvector, and how do they work?
An IVFFlat index divides vectors into clusters, called lists, using k-means. At query time, it compares the query with each cluster's centroid, searches only the closest clusters, called probes, and returns the nearest vectors found there.
Also asked as: what are ivfflat indexes in pgvector and how they work
Settings: lists sets the number of clusters at build time, often around rows divided by 1,000 for up to a million rows; ivfflat.probes sets how many clusters to search at query time, trading speed for recall. Build IVFFlat after loading representative data, since clusters come from existing vectors. HNSW usually offers better speed and recall without a training step, so IVFFlat is mainly useful when build time or memory matters more.
Why is my pgvector index not being used?
Common reasons: the query does not use ORDER BY embedding <operator> query LIMIT n, the operator does not match the index's operator class, such as cosine queries on an L2 index, the table is small enough that a sequential scan is cheaper, or filters and joins lead the planner to another plan.
Also asked as: why is the pgvector index not being used
Fixes: write queries in the order-by-distance-with-limit form, create the index with the operator class matching your distance, run ANALYZE after loading data, check plans with EXPLAIN ANALYZE, and for filtered queries consider partial indexes, partitioning or iterative scans in newer versions. Casting issues, such as comparing different dimensions, also prevent index use.
How do I enable pgvector in pgAdmin?
First install pgvector on the database server, or use a managed service that includes it. Then, in pgAdmin, open the Query Tool for your database and run CREATE EXTENSION vector;, or right-click Extensions under the database and create the "vector" extension through the dialog.
Also asked as: how to enable pgvector in pgadmin
You need privileges to create extensions. Confirm installation by expanding Extensions in pgAdmin or running SELECT extversion FROM pg_extension WHERE extname = 'vector';. If the extension is not listed as available, it is not installed on the server; pgAdmin is only a client and cannot install server software. Enable it separately in each database where you need vectors.






