pgvector
An open-source Postgres extension that adds a vector type and HNSW/IVFFlat indexes for similarity search inside your existing database.
pgvector turns Postgres into a vector database: it adds a vector column type, distance operators, and HNSW/IVFFlat indexes so you can run similarity search next to your relational data, with full SQL filtering and transactions — no separate vector store to operate.
pgvector is an open-source extension that gives Postgres a native vector type, distance operators, and approximate-nearest-neighbour indexes. With it, your embeddings live in the same database as your relational data — searchable with ordinary SQL, filterable with WHERE, and consistent inside the same transaction. For a large share of RAG and semantic-search workloads, that means there's no separate vector database to deploy, sync, or back up.
It is aimed at teams who already run Postgres and want vector search without adding a system. You install the extension, add a vector column, build an index, and query with the distance operators — the rest of your schema, joins, and tooling keep working as they always did.
Highlights
- Vector types in Postgres —
vector,halfvec(half-precision), andsparsevec, with distance operators for L2 (<->), cosine (<=>), and inner product (<#>). - HNSW & IVFFlat indexes — HNSW for high recall and low latency, IVFFlat for smaller memory footprints; both expose tuning parameters for the recall/speed trade-off.
- SQL-native filtering — combine similarity search with any
WHEREclause, join, orORDER BY— no separate metadata-filter API to learn. - Transactional & consistent — inserts and updates to vectors are ACID, just like the rest of your data.
- Scales further with extensions —
pgvectorscaleadds StreamingDiskANN and better quantization to push past in-memory limits while staying in Postgres.
In an AI-assisted workflow
Enable the extension, store embeddings beside your rows, index them, and query with a distance operator and a normal filter:
CREATE EXTENSION IF NOT EXISTS vector;
ALTER TABLE docs ADD COLUMN embedding vector(1536);
CREATE INDEX ON docs USING hnsw (embedding vector_cosine_ops);
-- nearest neighbours to the query vector, filtered by metadata
SELECT id, content
FROM docs
WHERE product = 'billing'
ORDER BY embedding <=> $1 -- $1 is the embedded query
LIMIT 20; -- over-retrieve, then rerankTIP
Match the operator class to your embedding model's distance metric — vector_cosine_ops for cosine, vector_l2_ops for Euclidean, vector_ip_ops for inner product. A mismatch silently degrades recall. To scaffold the schema and index, see Scaffold a pgvector Schema & HNSW Index.
Good to know
pgvector is free and open source under the permissive PostgreSQL License and ships in most managed Postgres offerings (Supabase, Neon, RDS, Cloud SQL). It's the pragmatic default when you already run Postgres and have up to a few million vectors; for billion-scale or heavy out-of-the-box quantization and sharding, weigh a dedicated store — see Best Vector Database in 2026. Tune the HNSW parameters against your recall target with the Embedding Index Tuner.
Related
- Best Vector Database in 2026: pgvector vs Pinecone vs Qdrant vs Weaviate vs Milvus vs Chroma vs LanceDBA decision guide to vector databases — embedded, server, or managed; whether you already run Postgres; and which fits your scale, filtering, and RAG needs.
- Scaffold a pgvector Schema & HNSW IndexScaffold a production-ready pgvector schema and HNSW index for a corpus — matching the project's migration tooling, distance metric, and embedding dimensions.
- Vector Search EngineerUse this agent to design, build, and tune the vector-database layer of a search or RAG system — schema and index design (HNSW/IVF + quantization), metadata/payload filtering, hybrid (dense + sparse) search, and ingestion/upsert pipelines — sized to a real latency, recall, and cost budget. Examples — "set up pgvector for our docs with HNSW and filtered search", "our Qdrant queries are slow and recall dropped after quantization", "add metadata filtering so search only returns the current tenant's documents".
- QdrantAn open-source vector database written in Rust, built for low-latency similarity search at scale.
- PineconeA fully managed, serverless vector database for similarity search and RAG — no nodes to run, indexes to tune, or infrastructure to operate.
- Embedding Index TunerTune a vector index — HNSW graph parameters and quantization — to hit a recall target at the lowest latency and memory, by sweeping settings against a fixed query set instead of trusting defaults. Use when vector search is slow or memory-hungry, when recall dropped after enabling quantization, or when standing up an index and you need defensible parameters.
- Postgres Index StrategistRecommend the right Postgres index for a query or workload — choosing B-Tree vs. GIN vs. BRIN vs. partial/covering/expression, checking for redundant or unused indexes, and verifying the choice against the query plan. Use when a query needs an index, when deciding an index type for jsonb/array/full-text/time-series data, or when auditing an over-indexed table.
- Indexing Postgres at Scale: B-Tree vs GIN vs BRIN and the Hidden Cost of Over-IndexingA practical guide to choosing Postgres index types — B-Tree, GIN, BRIN, partial, and covering — and why every index you add taxes every write.
- Zero-Downtime Postgres Migrations: The Expand-Contract Playbook for 2026How to change a live Postgres schema without downtime or broken deploys — the expand-contract pattern, safe column changes, batched backfills, and CONCURRENTLY.