Vector Database
A database optimised for storing and searching high-dimensional embeddings by similarity, powering semantic search and RAG.
· Reviewed by senior engineers
A vector database stores high-dimensional vectors — usually embeddings produced by an LLM or specialised embedding model — and answers nearest-neighbour queries against them. Given a query vector, return the k most similar stored vectors fast. Pinecone, Weaviate, Qdrant, Milvus, pgvector (Postgres) and the vector capabilities now built into Elasticsearch, MongoDB and many others all serve this role.
The use case is semantic similarity: "find documents about this question" rather than "find documents containing this exact phrase". That's what makes RAG, recommendation systems, image and audio similarity, deduplication and clustering possible at production scale.
The choice of vector database matters less than choice of embedding model and chunking strategy in most builds. The big architectural decisions are: do you need a dedicated vector DB or does pgvector inside your existing Postgres cover it (it usually does up to mid-millions of vectors)? Do you need hybrid search (semantic plus keyword)? And how do you re-index when the embedding model changes — because it will.
Devinsta defaults to pgvector or Qdrant for most builds and reaches for managed options like Pinecone only where scale or latency demand it. The boring choice is usually the right one.
Examples
- Pinecone
- Qdrant
- Weaviate
- pgvector
- Milvus