pgvector adds a vector data type and nearest-neighbor search operators directly to Postgres, so embeddings for search, recommendations, and RAG live next to the rest of your relational data instead of in a separate database. You get a vector column, distance operators, <-> for Euclidean, <=> for cosine, <#> for inner product, and an index type, HNSW or IVFFlat, that makes similarity search fast at scale. For most teams already running Postgres, it removes an entire category of infrastructure, a dedicated vector database, without giving up much search quality. It shipped as a Postgres extension in 2021 and has since become one of the most widely deployed pieces of AI infrastructure, largely because it requires no new operational skill set to run.
How it works
- Store embeddings in a
vector(n) column, where n matches your embedding model's dimension, 1536 for OpenAI's text-embedding-3-small, for example.
- Query with a distance operator ordered by nearest match:
SELECT * FROM docs ORDER BY embedding <=> $1 LIMIT 10;.
- Build an HNSW index for fast approximate nearest-neighbor search at query time, or an IVFFlat index if you need faster builds and can tolerate slightly lower recall.
- Combine the vector search with normal
WHERE clauses in the same query — filter by tenant, date, or status alongside the similarity ranking, something a separate vector database makes far more awkward.
What changed in 2026
- HNSW is now the default recommendation over IVFFlat for most workloads — better recall at similar query latency, at the cost of slower index builds.
- Iterative index scans were added so filtered vector queries no longer silently under-return results when the filter is selective.
halfvec and binary quantization cut storage and memory footprint significantly for large embedding sets, making pgvector viable at tens of millions of rows.- Every major managed Postgres provider ships it by default — RDS, Supabase, Neon, Timescale, and Cloud SQL all support pgvector with no extra setup.
pgvector vs dedicated vector databases
| Factor |
pgvector |
Pinecone / Weaviate / Qdrant |
| Operational overhead |
None — same Postgres instance |
Separate service to run or pay for |
| Joins with relational data |
Native SQL |
Requires app-side joins or duplication |
| Max practical scale |
Tens of millions of vectors, tuned |
Billions, built for it |
| Query latency at huge scale |
Good with HNSW, degrades further out |
Purpose-built, generally faster at extreme scale |
| Best for |
Most RAG apps, existing Postgres shops |
Very large-scale, dedicated search products |
In practice, most teams default to pgvector and only evaluate a dedicated vector database after measuring a genuine bottleneck, index build time, query latency at extreme scale, or a need for features like multi-tenant namespacing that pgvector does not provide natively.
Common mistakes
Skipping the index and wondering why search is slow. A sequential scan over embeddings is fine at a few thousand rows and falls apart past that — add an HNSW index before it becomes a production incident.
Mismatching the distance operator and how the model was trained. Cosine-similarity models need <=>; using <-> on normalized embeddings gives subtly wrong rankings.
Storing full-precision vectors when halfvec would do. At millions of rows, halved storage is a real cost and memory win with minimal recall loss.
Assuming pgvector scales identically to a dedicated vector database. It scales very well, but at extreme scale, hundreds of millions of vectors with tight latency SLAs, a purpose-built vector database still has an edge.
FAQ
Is pgvector fast enough for production RAG?
Yes, for the overwhelming majority of RAG applications — millions of documents with an HNSW index comfortably hits sub-100ms queries.
Do I need a separate vector database if I already use Postgres?
Usually not. Add pgvector to your existing instance first, and only migrate to a dedicated vector database if you hit a specific, measured scale or latency wall.
What embedding dimension should my column use?
Match it to your embedding model exactly — 1536 for OpenAI's small embedding model, 3072 for the large one, or whatever your chosen model outputs.
Can I combine full-text search with vector search?
Yes — hybrid search, Postgres full-text search plus pgvector similarity, combined with reciprocal rank fusion, is a common and effective pattern in 2026.
Does pgvector support metadata filtering?
Yes — because vectors live in ordinary Postgres rows, filtering by any column, tenant ID, category, or date is just a normal WHERE clause combined with the similarity ordering.
Where to go next
For the data-access side of a pgvector-backed app, design patterns explained in 2026 covers the Repository pattern that keeps embedding queries out of your route handlers, and how to build a REST API in Node in 2026 is a solid reference for the surrounding service. If you are hardening the same database, read SQL injection prevention in 2026.