Key facts
| Definition | A store that indexes embeddings and returns nearest neighbours for a query |
| Why it matters | Powers semantic search and RAG retrieval beyond keyword matching |
| How Plugsky fits | Embedding endpoints generate vectors; the vector store is your choice |
| Core features | ANN indexes, metadata filtering, upserts and hybrid search variants |
| Embedding models | Dedicated embedding models are live, including multilingual options |
| Scale factors | Dimensions, index type, filter selectivity and update rate drive performance |
| Alternatives | Relational databases with vector extensions or in-process indexes for small corpora |
| Status | Embeddings and chat completions are live; pair them with any vector store |
TL;DR
- A vector database answers 'what is semantically near this query'.
- Plugsky makes the vectors; the store is your architectural choice.
- Metadata filters are as important as similarity ranking.
- Start in-process; move to a managed store when scale demands it.
- Re-embed when you change embedding models — dimensions and spaces differ.
How it works, step by step
- Choose an embedding model that fits your language coverage and dimension budget.
- Chunk documents and generate embeddings through the live embeddings endpoint.
- Store vectors with metadata: source, section, timestamps and access labels.
- Create an approximate nearest neighbour index appropriate to your scale and recall target.
- Query with filters first, then rank by similarity, and return bounded results.
- Plan reindexing for model changes and data updates, and monitor recall.
Try it yourself
Open the embedding model comparison →
What a vector database does
An embedding turns content into a vector. A vector database stores those vectors and finds the ones closest to a query vector using an approximate nearest neighbour index. That is semantic retrieval: results match meaning rather than exact keywords. Production stores add metadata filtering, upserts, deletions and often hybrid scoring that blends vector similarity with keyword relevance.
When you need one
- RAG systems: retrieving passages for grounded generation.
- Semantic search: finding results by meaning in docs or catalogues.
- Recommendations: matching items by embedding similarity.
- Deduplication and clustering: grouping near-identical content.
- Multimodal search: cross-modal retrieval using a shared embedding space.
Small corpora can live in memory or in a relational table with a vector extension — a dedicated database is a scaling decision, not a starting requirement.
Common mistakes
- Embedding with one model and querying with another, so vectors live in different spaces.
- Retrieving by similarity without filters, returning stale or unauthorized content.
- Ignoring dimension cost: larger vectors mean more storage and slower queries.
- Never reindexing after chunk or model changes.
- Choosing a store before defining query patterns, filters and update volume.
Vector databases with Plugsky
Plugsky provides the vector source, not the store: live embedding endpoints convert your content and queries, and chat completions generate grounded answers from what you retrieve. Because the API is OpenAI-compatible, an existing RAG stack connects after changing the base URL, and dedicated embedding models handle multilingual or domain-specific content. Provenance metadata, access filtering and reindexing remain your responsibility — that division keeps data custody with you while Plugsky handles model serving.
Start with the simplest store that meets your query and filter needs.
Honest comparison
| Option | In-process index | Relational plus vectors | Managed vector database |
|---|---|---|---|
| Setup effort | Lowest | Low | Moderate |
| Scale ceiling | Corpus sized to RAM | Millions of rows | Very large |
| Metadata filters | Basic | Full SQL | Native and fast |
| Ops burden | None | Existing database ops | Vendor managed |
| Best for | Prototypes and small apps | Teams already on SQL | Production RAG at scale |
Frequently asked questions
What is a vector database?
A database that stores embeddings and retrieves the vectors nearest to a query, powering semantic search, recommendations and RAG retrieval.
Do I need a vector database for RAG?
Not necessarily. Small corpora work with an in-process index or a relational vector extension. A dedicated store becomes worthwhile as data volume, filters and update rates grow.
Does Plugsky provide a vector database?
No. Plugsky provides live embedding models and chat completions. You choose and operate the vector store, which keeps data custody with you.
How do metadata filters interact with similarity search?
Filters narrow the candidate set before or during ranking, enforcing access control and freshness. Retrieval without filters can surface stale or unauthorized passages.
What happens if I change embedding models?
You must re-embed the corpus. Different models produce different dimensions and vector spaces, so mixed embeddings break retrieval.
Which embedding model should I start with?
One that covers your languages and fits your dimension budget. Compare options with the embedding model comparison tool, then validate retrieval quality on your data.