pgvector is a PostgreSQL extension that stores and searches embeddings. It means the vectors live in the same database as the records they describe, in the same transaction and the same backup — which removes the consistency problem a separate vector database introduces on day one.
What is pgvector?
Retrieval works by turning text into a list of numbers — an embedding — and finding the closest ones to a question's embedding. That requires somewhere to store vectors and an index that can search them quickly.
pgvector adds exactly that to PostgreSQL. The vector becomes a column on the row it belongs to, and similarity search becomes part of an ordinary SQL query — which means it can be combined with a WHERE clause in the same statement.
That last point is the one that matters in practice. Real retrieval is rarely pure similarity; it is "the closest matches, in this tenant, that this user may see, from the current version of the document". In Postgres that is one query.
When we choose pgvector
Below roughly a million vectors, which covers nearly every project we scope. A mid-market company's entire document estate chunks down to somewhere between thirty thousand and three hundred thousand vectors, and pgvector answers that in single-digit milliseconds on hardware already being paid for.
Whenever the embedding must stay consistent with the record. One transaction means a document and its vector cannot get out of step, which is the failure a second datastore introduces silently.
And whenever filtering by tenant, permission or date is part of the query — which is almost always.
When we do not use pgvector
Above a few million vectors with heavy query load, where a purpose-built vector database genuinely outperforms it. That threshold is far above where most projects sit, and we recommend moving when the measurement says so rather than when the architecture diagram looks more impressive with one on it.
And when the client is not on PostgreSQL and has no reason to move.
What we build with pgvector
Retrieval over multi-tenant document sets
Where each client, branch or department must only ever see its own documents. Filtering by tenant in the same query as the similarity search makes leakage a schema property rather than something the application has to remember.
Semantic search on an existing catalogue
Products, articles or listings searchable by meaning rather than keyword, without moving the catalogue out of the database it already lives in.
Duplicate and near-match detection
Finding the same customer entered three times with different spellings, or a supplier invoice submitted twice. Similarity search finds what an exact match never will, and it is one of the clearest returns on the technique.
Related-content recommendations
Suggesting the article, product or case study closest in meaning to what someone is reading, computed in the database with no separate recommendation service to run.
How we ship pgvector projects
With an HNSW index sized against the actual corpus, and p95 query time tracked from launch so the ceiling is measured rather than guessed at.
Embeddings regenerated automatically when the source text changes, in the same transaction as the update. A stale embedding is the silent version of a wrong answer.
With the chunking strategy chosen against your actual documents rather than a default. Chunk size decides retrieval quality more than the model does, and the right size for a policy manual is not the right size for a product catalogue.
What pgvector costs you
At very large scale a dedicated vector database will outperform it, and the migration is roughly a day when the numbers say it is time.
Index tuning also matters more than people expect: the defaults are fine at small scale and need attention as the corpus grows, which is why we track query time from the start rather than waiting for someone to complain.
Building the index on a large corpus takes memory and time, and it has to be rebuilt when the embedding model changes. That last point catches people out — switching to a better model means regenerating every vector, which is a scheduled job rather than a config change.
pgvector questions we get asked
Below about a million vectors, almost certainly not. pgvector in the Postgres you already operate is fast enough and removes an entire class of consistency bug. Move when you have measured the ceiling, not before — the migration is about a day of work.
Comfortably up to around a million vectors on ordinary hardware, which for most companies is their entire document estate several times over. We measure p95 query time from launch so you know where the ceiling actually is rather than guessing.
Its embedding is regenerated in the same transaction as the change, so the two can never disagree. A stale embedding is a silent bug — the assistant answers confidently from text that no longer exists, and nobody finds out for weeks.
Yes — the vector does not care what language produced it, so an Arabic question can find an English passage and the reverse, provided the embedding model handles both. That cross-language behaviour is one of the more useful properties for bilingual document sets and is worth testing on your own content early.
Nothing in licensing — it is an open-source extension. The cost is the embedding generation, which is a one-off API charge proportional to how much text you have, plus a little extra database memory. For a typical corpus that is tens of dollars, not thousands.
The tenant is a column on the same row as the vector, and the similarity search filters on it in the same query. That makes isolation a property of the database rather than something the application has to remember on every code path — which is the difference between a guarantee and a convention.