Contents
A vector database stores embeddings — numerical representations of the meaning of text, images or products — and quickly finds those closest to a query. It powers semantic search, recommendations and AI assistants that answer from your documents. If your project already runs on PostgreSQL, the pgvector extension is enough in most cases; a dedicated vector database pays off at very large volumes.
Here is how vector search works, when pgvector is enough, when you need a dedicated solution and how to make search more accurate.
What are embeddings and vector search?
An embedding is a vector of hundreds or thousands of numbers that a model builds from text so that texts with similar meaning get similar vectors. Vector search finds records whose vectors are closest to the query vector — so it treats "how do I get my money back" and "request a refund" as the same question.
Where vector search is used:
- AI assistants over documents — finding relevant passages before the model answers;
- semantic search on a website or in a knowledge base;
- recommendations — similar products, articles, job openings;
- duplicate detection — identical support tickets or product listings;
- classification — routing requests by topic.
We covered building an assistant over your documents in RAG: an AI assistant for your own documents.
When is pgvector enough?
pgvector is enough if you already run PostgreSQL, have up to a few million vectors and need to combine vector search with ordinary filters — access rights, category, date. The main advantage is that data, permissions and vectors live in one database and one transaction.
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE document_chunks (
id bigserial PRIMARY KEY,
document_id bigint NOT NULL,
content text NOT NULL,
embedding vector(1536) NOT NULL
);
CREATE INDEX ON document_chunks USING hnsw (embedding vector_cosine_ops);
SELECT id, content
FROM document_chunks
WHERE document_id IN (SELECT id FROM documents WHERE team_id = 42)
ORDER BY embedding <=> $1
LIMIT 5;
More on choosing and tuning the database in PostgreSQL vs MySQL and PostgreSQL indexes.
Photo: Unsplash
When do you need a dedicated vector database?
A dedicated vector database is needed with tens or hundreds of millions of vectors, very high query volumes and single-digit-millisecond latency requirements, or when you need features pgvector lacks: distributed storage, built-in hybrid search, collection-level multi-tenancy.
| Criterion | pgvector | Dedicated vector database |
|---|---|---|
| Volume | Up to a few million vectors | Hundreds of millions and more |
| Infrastructure | Already there | A separate service or cloud |
| Filters on regular data | SQL, in the same transaction | Metadata, synced with the main database |
| Data consistency | Full | Requires syncing |
| Scaling | Vertical, replicas | Horizontal |
How do you make vector search more accurate?
Vector search accuracy depends less on the database than on data preparation: how documents are chunked, which model builds the embeddings and whether vector search is combined with ordinary full-text search. A hybrid approach usually wins.
- Chunking. Split by meaningful blocks — sections, paragraphs — not by a fixed number of characters.
- Metadata. The document title, section and date next to each chunk improve both search and answers.
- Hybrid search. Merging vector and full-text results helps with SKUs, names and exact terms — see site search.
- Reranking. A separate model reorders the candidates by relevance.
- Quality evaluation. A set of test questions with correct answers shows whether changes made things better.
How much does vector search cost?
The main costs are building embeddings, keeping vectors in memory and calling the model on every query. Embedding a medium-sized knowledge base is cheap and done once, but index memory and reindexing on model changes become noticeable at scale.
- build embeddings once on upload and recompute only changed documents;
- vector size affects memory — lower-dimensional models are cheaper to store;
- cache embeddings of frequent queries;
- plan for reindexing when the model changes.
How to estimate an AI feature as a whole: AI feature cost.
In short
- Embeddings represent meaning as vectors; vector search finds the nearest ones.
- It powers AI assistants, semantic search, recommendations and duplicate detection.
- With PostgreSQL and up to a few million vectors, pgvector is enough.
- A dedicated database pays off at hundreds of millions of vectors and strict latency needs.
- Chunking, metadata, hybrid search and reranking improve accuracy.
FAQ
How many vectors can pgvector handle?
Millions of vectors on an ordinary server with enough memory. The limit is usually index memory and build time, not the database itself.
Do embeddings need recomputing when the model changes?
Yes. Vectors from different models are incompatible, so changing the model means reindexing every document. Store source texts and the model name alongside the vectors to make this easy.
Can personal data be stored in a vector database?
Yes, but vectors are subject to the same requirements as the source data: permission-based access, deletion on request, storage in the right jurisdiction. Some meaning of the text can be recovered from an embedding.



