Key takeaways
- A vector store holds numerical representations of text so that similar meaning can be found quickly.
- For many applications, Postgres with the pgvector extension is simple, familiar and sufficient.
- Dedicated vector databases make sense at very large scale or when you need specialised features.
- Search quality often depends more on chunking, hybrid keyword search and re-ranking than on the database brand.
- Choose the simplest option that meets your needs, and keep your data model portable.
What a vector store does
AI retrieval systems turn passages of text into lists of numbers called embeddings, which capture meaning. To answer a question, the system turns the question into an embedding too and finds the stored passages that are closest. A vector store keeps those embeddings and performs that similarity search quickly. This is the retrieval step of RAG.
The options
| Postgres + pgvector | Dedicated vector database | Search engine (hybrid) | |
|---|---|---|---|
| What it is | An extension to a database you may already run | A specialised service built for similarity search | A search platform that combines keywords and vectors |
| Strengths | One system, joins with your data, simple operations | Scale, speed and tuning options | Strong relevance, filters and ranking |
| Trade-offs | Needs tuning at very large sizes | Another service to run and secure | More to configure |
| Good fit | Most business apps and prototypes | Very large collections, heavy traffic | Search-centred products |
Why pgvector is often enough
- Your application data and embeddings live together, so permission filters and joins are easy.
- You already know how to back up, secure and monitor Postgres.
- Fewer moving parts means fewer things to break and lower cost.
- Many production assistants work with thousands to a few million passages, which Postgres can handle with proper indexing.
When to consider something else
- You expect hundreds of millions of vectors or very high query volume.
- You need advanced features such as specialised filtering at scale or multi-tenant isolation that your database struggles with.
- Search quality is your product, and you want a mature search engine with ranking controls.
Measure before you migrate. Many teams move too early to a heavier system when the real issue was poor chunking or missing keyword search.
What affects quality more than the database
- Chunking. Passages that respect document structure retrieve far better than arbitrary slices.
- Hybrid search. Combining keyword and semantic matching catches exact terms such as product codes.
- Re-ranking. A second pass puts the best passages first.
- Metadata. Dates, sources and permissions make results trustworthy and safe.
Cost also depends on how much you send to the model, which we cover in our guide to reducing LLM API costs. If you are unsure which store suits your data and traffic, our RAG development team can benchmark the options on your own content.