Vector Store
A vector store is a database optimized for storing and searching embeddings — high-dimensional numeric representations of text, images, or other data — used as the retrieval layer in RAG systems.
When you 'index' a document for AI use, you split it into chunks, run each chunk through an embedding model, and get back a vector (a list of numbers, usually 768–4096 long). The vector store keeps those vectors and supports approximate-nearest-neighbor search: 'give me the 10 chunks most similar to this query embedding'. Popular vector stores in 2026: pgvector (Postgres extension — most common), Pinecone, Weaviate, Qdrant, Chroma, LanceDB. For most teams, pgvector inside the existing Postgres is the right call until volume forces specialization.
Example
Acme uploads 5,000 support tickets. Each ticket is embedded and stored in pgvector. When a customer asks a new question, the AI embeds the question, finds the 5 nearest historical tickets, and uses them as context for the answer.
How OpenLabor uses it
OpenLabor manages a vector store per employee so each one has its own scoped knowledge base.
Do I need a dedicated vector database?
Often no. pgvector handles tens of millions of vectors well. Specialized vector DBs win at very large scale or when you need exotic features.
Why are my vector search results bad?
Usually chunking, not the database. Bad chunks make bad embeddings. Try semantic chunking, overlap, and adding a re-ranker.
Related: rag, embedding.
AI Labor Glossary