What Is a Vector Database?
A vector database stores text, images, or other data as high-dimensional numerical vectors called embeddings. When you query it, the database finds the entries whose vectors are closest to your query vector, returning semantically similar results even when no keywords match. Vector databases are the storage layer behind retrieval-augmented generation (RAG) systems and AI-powered search.
A vector database stores data as numerical embeddings and retrieves results by semantic similarity rather than exact keyword matches. It is the storage layer behind most modern AI search systems.
How Embeddings Work
An embedding model takes a piece of text and outputs a list of numbers, typically hundreds or thousands of them. This list is called a vector. The key property is that texts with similar meanings produce vectors that are close together in mathematical space, while texts with different meanings produce vectors that are far apart.
For example, the phrases “quarterly revenue report” and “Q3 financial results” produce vectors that are very close to each other, even though they share no words. A keyword search would miss this connection. A vector search finds it easily.
Embedding models are trained on large text corpora and learn to encode semantic relationships. OpenAI, Cohere, and open-source projects like Sentence Transformers all provide embedding models you can use via API or run locally.
The Role of Vector Databases in RAG
Retrieval-augmented generation is the technique of giving a language model access to an external knowledge base before it generates an answer. The process works like this: your documents are embedded and stored in a vector database, a user asks a question, the question is also embedded, the vector database retrieves the most relevant document chunks, and those chunks are included in the prompt sent to the language model.
Without a vector database, the model can only answer from its training data. With one, it can answer accurately from your internal documents, product manuals, contracts, or any private knowledge base. This is also how AI agents access up-to-date information beyond their training cutoff.
Popular Options
pgvector: A PostgreSQL extension that adds a vector column type and similarity search operators. If you already use Postgres, this is the lowest-friction starting point. It handles millions of vectors well and supports filtering by other columns alongside vector similarity.
Pinecone: A fully managed cloud vector database. You upload vectors via API and query them without managing any infrastructure. It scales to billions of vectors and includes metadata filtering. The trade-off is cost and vendor dependency.
Weaviate: An open-source vector database you can self-host or use as a managed service. It combines vector search with structured filtering and supports multiple embedding models out of the box.
Qdrant: Another open-source option with a focus on performance and a clean API. Popular in self-hosted and on-premise deployments.
When You Need One
You need a vector database when your application must search by meaning rather than by exact values. Common use cases include: internal document search, customer support bots that answer from a knowledge base, product recommendation engines, and duplicate detection in large datasets.
You do not need a vector database for simple structured queries. If you are looking up a user by email address or filtering orders by date range, a relational database is faster, simpler, and cheaper. Vector databases add complexity; introduce them only when semantic search is genuinely part of your product.
Choosing the Right Scale
The performance of vector search depends on the number of vectors and the dimensionality. For tens of thousands of vectors, almost any option works including in-memory libraries. For millions of vectors, pgvector with proper indexing (HNSW or IVFFlat) handles it well. For hundreds of millions of vectors with low-latency requirements, dedicated managed services become worth the cost.
Start small. Most business applications need far fewer vectors than developers assume. A company knowledge base with a few thousand documents is well within pgvector’s range and requires no additional infrastructure.
Our tip: Before choosing a vector database, decide which embedding model you will use and check the vector dimensions it produces. All vectors in a collection must have identical dimensions, so switching embedding models later means re-embedding all your data. Getting this decision right early saves significant rework.
Frequently asked questions
What is the difference between a vector database and a regular database?
A regular relational database searches by exact values: find all rows where name equals 'invoice'. A vector database searches by similarity: find the 10 entries most semantically similar to this query. Regular databases are fast and precise for structured lookups. Vector databases excel when meaning matters more than exact wording, which is common in AI applications. Many teams use both: a relational database for structured data and a vector database for semantic search.
Do I need a separate vector database or can I use my existing database?
PostgreSQL with the pgvector extension supports vector storage and similarity search directly. If you already run Postgres, pgvector is the easiest starting point and handles moderate scale well. Dedicated vector databases like Pinecone or Weaviate offer better performance at very large scale and include additional features like metadata filtering and managed indexing. Start with pgvector unless you have strong evidence you will exceed its limits.
What does 'dimensions' mean in the context of embeddings?
Dimensions refer to the length of the numerical vector. An embedding model might produce a 1536-dimensional vector, meaning a list of 1536 numbers. More dimensions generally capture richer meaning but require more storage and compute to search. The number of dimensions is fixed by the embedding model you choose, so all vectors in a collection must have the same number of dimensions.