What Is a Vector Database: A Plain-English Definition
A vector database stores data as high-dimensional numerical arrays called vectors, alongside metadata and the original content. Unlike a relational database that stores rows and columns of typed data and finds records via exact matches or range queries, a vector database stores arrays of floating-point numbers (typically 768 to 3,072 dimensions) and finds records via similarity search. The key query pattern is: given a query vector, find the K stored vectors that are closest to it in terms of a distance metric, typically cosine similarity or Euclidean distance. This is called approximate nearest-neighbour (ANN) search. The 'approximate' qualifier is important. Exact nearest-neighbour search over billions of high-dimensional vectors would be computationally prohibitive. ANN algorithms like HNSW (Hierarchical Navigable Small World) and IVF-PQ trade a small amount of accuracy for dramatic speed improvements, enabling sub-10ms queries over hundreds of millions of vectors. Vector databases also support filtering. You can search for vectors similar to your query but only within a subset of records matching metadata criteria. For example: 'find documents similar to this query, but only from the last 30 days and from the Contracts category.' This hybrid search combining semantic similarity with metadata filtering is what makes vector databases practical for real product use cases.
How Vector Databases Work
The workflow begins with ingestion. You take your source content, split it into chunks, generate an embedding vector for each chunk using an embedding model, and store the vector alongside the original text and any metadata (document ID, date, category, user ID, etc.) in the vector database. The database builds an index over these vectors to enable fast retrieval. At query time, you embed the user's query using the same embedding model, then search the vector database for the nearest neighbours. The database returns the top-K most similar chunks, which you then pass to an LLM to generate a grounded response. This is the standard RAG pipeline. Consider a concrete example. A UK financial services firm builds an AI tool that lets relationship managers query client files. They ingest 50,000 client documents, generating approximately 500,000 chunks with metadata including client ID, document type, and date. These vectors are stored in Pinecone. A relationship manager queries 'what investment restrictions does client Thornton have?' The query is embedded, matched against client Thornton's document subset via metadata filtering, and the top three relevant chunks are retrieved. The LLM synthesises those chunks into a clear answer with citations. Leading vector database options include Pinecone (fully managed, production-proven, expensive at scale), Weaviate (open-source with a managed cloud option, strong hybrid search), Qdrant (fast, open-source, good for self-hosted deployments), and pgvector (a PostgreSQL extension that is excellent for lower volumes and reduces infrastructure complexity).
Why Vector Databases Matter for AI Product Development
Vector databases matter because they enable the retrieval half of retrieval-augmented generation, which is the dominant architecture for production knowledge-grounded AI products. Without a fast, scalable mechanism for finding relevant chunks from a large corpus, RAG either requires sending enormous context windows (expensive and slow) or cannot scale beyond toy-sized document sets. The quality of your vector retrieval directly affects the quality of your LLM's responses. If the wrong chunks are retrieved, the LLM either hallucinates for lack of relevant context or generates a response grounded in the wrong information. Getting retrieval right is often more impactful than fine-tuning your prompts or switching to a better model. For product teams, the vector database decision also affects operational complexity and cost. A separate vector store is another managed service to provision, monitor, and pay for. For early-stage products with modest document volumes (under 100,000 vectors), pgvector running alongside your main PostgreSQL database often provides adequate performance with no additional infrastructure. The decision to adopt a dedicated vector database should be driven by concrete latency or scale requirements, not by what the architecture diagrams in AI tutorials show. Data residency is a relevant concern for UK and EU products. If your vector store processes personal data, you need to ensure the vector database provider meets your GDPR data residency requirements. Pinecone and Weaviate both offer EU region deployments.
Common Use Cases for Vector Databases
Enterprise knowledge retrieval is the most common production use case. Companies with large internal documentation bases use vector databases to enable employees to ask questions and receive answers grounded in current company documents. Law firms, consultancies, and financial services firms are heavy adopters because their competitive advantage is embedded in proprietary knowledge bases. Customer-facing AI assistants that need to answer questions about a product, service, or domain without hallucinating use vector databases to store and retrieve the grounding context. E-commerce product search benefits from semantic understanding of product descriptions. A search for 'comfortable shoes for long days on my feet' returns relevant results even when the product descriptions use different phrasing. Code search and developer tools use code embeddings to enable semantic search over large codebases. 'Find all functions that handle user authentication' works even when the function names or comments use different words. Fraud and duplicate detection use vector similarity to identify near-identical records. Insurance claims with very similar narratives, support tickets that are essentially duplicates, or product listings that are reworded copies can all be identified using ANN search against a vector store. For UK healthtech applications, embedding patient records or clinical notes for retrieval requires explicit planning for GDPR right to erasure. Vector databases need to support deletion of specific vectors corresponding to a patient's data, and any derived indexes need to be updated or rebuilt after deletion.
Related Concepts You Need to Know
Embeddings are the vectors that vector databases store. You cannot use a vector database without first generating embeddings using a model like OpenAI's text-embedding-3 series or Cohere Embed. The choice of embedding model affects the dimension of vectors you store, the quality of similarity matching, and the cost of generating embeddings at scale. Semantic search is the primary query capability that vector databases enable. Understanding how cosine similarity and ANN search work helps you debug retrieval failures and tune chunking strategies and embedding models. Retrieval-augmented generation is the architecture that most commonly incorporates a vector database in a production AI product. The vector database is the retrieval mechanism; the LLM is the generation mechanism. Getting both right is necessary for a reliable AI product. AI orchestration frameworks like LangChain and LlamaIndex both include built-in integrations with major vector databases. LlamaIndex in particular is designed around the data indexing and retrieval problem and provides higher-level abstractions for building RAG pipelines with common vector stores. Data residency and multi-tenancy are architectural concerns for enterprise SaaS products. If your product serves multiple customers and each customer's documents should be isolated, you need to implement tenant isolation in your vector store. This is typically achieved through metadata filtering by tenant ID, though full physical isolation requires separate collections or namespaces per tenant.