ModelRefs / pgvector — AI Glossary
pgvector — AI Glossary
A PostgreSQL extension adding vector similarity search, enabling RAG applications without a separate vector database.
Overview
pgvector (open source, 2021) adds a vector column type and IVFFlat/HNSW indexes to PostgreSQL. Supports exact and approximate nearest-neighbor search using L2, inner product, and cosine distances. Ideal for teams already on Postgres seeking minimal infrastructure overhead. Used by Supabase, Neon, and AWS RDS for vector workloads.
Reference details
| Topic | rag |
|---|---|
| Last reviewed | 2026-06-24 |
Related terms
How it works
- A vector column type is added to the relational database, so embeddings live in ordinary tables alongside the rows they describe.
- Distance operators for the usual metrics let similarity appear directly in a query's ordering clause, which is what makes vector search expressible in the same language as everything else.
- Two index families are available: an inverted-file approach that partitions vectors into lists and probes a subset, and a graph-based approach that traverses neighbours. The first builds faster and needs representative data; the second queries faster and costs more to build.
- Both are approximate, with a tunable parameter trading recall against latency — the number of lists probed, or the size of the candidate list during traversal.
- The decisive advantage is that a metadata predicate and a similarity ordering are one query against one transactional store, so the filter is applied by a planner that can see both rather than by application code joining two systems.
- The decisive limit is that this is a general-purpose database doing vector search rather than a system built for it, so sharding, replication and memory management for very large vector sets are not its strengths.
Example: Where the size threshold actually sits
A million 768-dimensional vectors in 32-bit floats occupy 1,000,000 x 768 x 4 = 3,072,000,000 bytes, about 3.07GB, before index overhead — comfortable for a database server with ordinary memory, and the graph index on top typically adds a substantial fraction again. At a hundred million vectors it is 100 x 3.07 = 307GB of raw vectors, which is a different class of problem: beyond single-node memory, requiring sharding the general-purpose database was not designed to do for this workload. So the threshold is not a fixed number of rows but whether the vectors and their index fit in the memory of a machine you are willing to run, and the arithmetic above puts that in the low tens of millions for typical embedding widths. Below it the consolidation argument is strong, because one system means one backup, one access-control model, one transaction boundary and filtered search that a query planner handles. Above it the dedicated systems exist for reasons that start to apply.
Commonly confused with
This is an extension to a general-purpose database, not a vector database, and the difference shows up in operations rather than in query results. A dedicated vector system offers horizontal sharding, replication tuned for vector workloads, memory-resident index management and native multi-tenancy by partition. The extension offers transactions, joins, a mature access-control model, a query planner that can combine predicates with similarity, and the fact that you are already running it. For corpora that fit on one node the second list usually wins; the first list is what you need when they do not.
When to use it
Reach for it when:
- Teams already operating this database, where consolidation avoids a second datastore entirely.
- Corpora in the millions rather than hundreds of millions of vectors, where a single node holds vectors and index.
- Queries combining structured predicates with similarity, where one planner handling both beats application-side joining.
- Where transactional consistency between a row and its embedding matters, which separate systems cannot provide.
Reach for something else when:
- Very large vector sets, where the memory and sharding requirements exceed what a general-purpose database does well.
- Workloads needing vector-specific operational features — native partition-level multi-tenancy, vector-aware replication.
- Extreme query throughput, where a purpose-built system's index management and memory layout matter.
- Without tuning the recall parameter, since both index types are approximate and the default is not a recall guarantee.
Continue your research
Use these connected ModelRefs sections to compare alternatives, inspect implementation paths, and review the evidence and governance boundaries relevant to pgvector — AI Glossary.
Frequently asked questions
What is pgvector?
A PostgreSQL extension adding vector similarity search, enabling RAG applications without a separate vector database.
What concepts are related to pgvector?
Closely related concepts include faiss, ann, dense retrieval.