A vector database is a database built to store and search embeddings — the lists of numbers an AI model uses to represent the meaning of text, images, or audio — so that an application can instantly find the items whose meaning is closest to a given query, rather than the items that merely share the same keywords.

Why ordinary databases aren’t built for this

A conventional database is built for exact or partial matches: find the row where email = 'x@y.com', or where a title contains a word. That works well for structured records, but it fails at a different kind of question: “find the paragraph that means roughly the same thing as this one,” or “find the product image that looks like this photo.” Meaning isn’t a string you can match with LIKE — it has to be represented some other way.

That other way is the embedding. An embedding model reads a piece of text (or an image, or a sound clip) and outputs a vector — typically a few hundred to a few thousand floating-point numbers — that places it as a point in a high-dimensional space. The model is trained so that items with similar meaning end up as nearby points, and unrelated items end up far apart. Two sentences that describe the same idea in different words can produce almost the same vector, even though they don’t share a single keyword.

How the search actually works

Once data is turned into vectors, the database’s job is to answer one question fast, over and over: given a new query vector, which stored vectors are closest to it? “Closest” is usually measured with cosine similarity or Euclidean distance, and the underlying computational problem is called nearest neighbor search.

Comparing a query against every single stored vector (a brute-force scan) gives exact results but doesn’t scale — it gets slow once a collection reaches millions of entries. Vector databases instead build an index using approximate nearest neighbor (ANN) algorithms, most commonly a graph structure called HNSW (Hierarchical Navigable Small World) or a clustering method like IVF (Inverted File Index). These trade a small amount of accuracy for a large speedup, typically returning results in single-digit to low double-digit milliseconds even across tens of millions of vectors. Most also support “hybrid search,” combining the vector similarity score with a traditional keyword filter, so a query can be both semantically relevant and constrained to, say, a specific product category or date range.

Why it matters

Vector databases are the piece of infrastructure that makes semantic search practical at application scale, and they are the standard storage layer behind retrieval-augmented generation, the technique that lets a chatbot answer questions using a company’s own documents instead of only what a large language model memorized during training. In a typical RAG setup, incoming documents are split into chunks, each chunk is embedded and stored in the vector database, and at query time the user’s question is embedded and matched against those stored chunks to pull back the most relevant passages before the model writes an answer.

The same mechanism powers recommendation engines (find products similar to ones a user liked), image and audio search (find visually or acoustically similar files), duplicate and fraud detection, and anomaly detection — anywhere “similar to this” is a more useful question than “equal to this.”

Getting started

Developers who already run PostgreSQL can add vector search with pgvector, a free, open-source extension that stores embeddings alongside ordinary relational data and requires no separate system to operate. It comfortably handles collections up to a few million vectors on modest hardware. For larger or more demanding workloads, fully managed services such as Pinecone, or open-source systems built specifically for vector search such as Weaviate and Milvus, are the common alternatives — the tradeoff is usually operational simplicity (managed) versus cost control and self-hosting flexibility (open-source).

Managed vector databases are usually priced by storage and query volume rather than a flat seat fee. Pinecone, for example, offers a free “Starter” tier (up to 2GB of storage and a monthly allowance of read/write operations), with paid usage-based plans starting at a $20/month flat “Builder” tier and a “Standard” tier billed at a $50/month minimum, as of July 2026, per Pinecone’s pricing page. Self-hosting pgvector, Weaviate, or Milvus avoids that bill entirely in exchange for running and scaling the database yourself.

FAQ

Is a vector database the same thing as a regular database with a search feature bolted on?
No. Ordinary “full-text search” still matches keywords and their variants. A vector database compares meaning by measuring distance between embeddings, so it can match a query to a passage that expresses the same idea in completely different words.

Do I need a dedicated vector database, or can I just add a vector column to Postgres?
For most applications under a few million vectors, an extension like pgvector inside a database you already run is simpler and cheaper than adding a new system. Dedicated vector databases earn their keep at larger scale or when you need features like real-time index updates across billions of vectors.

Can a vector database replace a large language model?
No — they solve different problems. The vector database finds relevant information; the language model reads that information and generates a response. In a RAG pipeline, they work together: retrieval first, generation second.

Does the choice of embedding model matter?
Yes. Vectors from two different embedding models generally aren’t comparable to each other, so a database is built around one model’s output space at a time; switching embedding models later usually means re-embedding and re-indexing the data.