What Is a Vector Database?

The Library Catalog Problem

Imagine a giant library. A traditional catalog tells you where every book lives by title, author, and ISBN. Ask for "The Great Gatsby" and you get row 12, shelf 4. Perfect. But what if you ask for "books that feel like The Great Gatsby - melancholy, wealthy social circles, the American Dream gone sour"? The catalog has no idea how to answer that. It can only do exact matches.

That is the problem vector databases solve.

A regular database is the alphabetical catalog: excellent at exact lookups, useless for meaning-based search. A vector database is something closer to a very well-read librarian who has absorbed every book and can point you to thematically similar ones even when the titles share no words.

What a Vector Actually Is

A vector is a list of numbers. In machine learning, when a model reads a piece of text, looks at an image, or processes a product description, it produces a vector as its output - a long list of numbers (often hundreds or thousands of them) that captures what that thing means in a mathematical sense.

Think of it as coordinates. Except instead of three dimensions like a map, you have 768 or 1,536 dimensions. Things with similar meaning end up at similar coordinates. "Car," "automobile," and "vehicle" cluster near each other. "Car" and "banana" sit far apart.

When you store these vectors in a vector database, you are storing the meaning of your content in a form the machine can search.

Why You Cannot Use SQL LIKE for Semantic Search

A SQL LIKE query matches characters, not concepts. If you search for "contract termination," it will miss a paragraph that says "agreement cancellation provision," even though they mean the same thing. You would have to anticipate every synonym and variant and hard-code them - an impossible task at scale.

Vector search does not care about word choice. It compares meaning. Two sentences can share zero words and still score as semantically close because their vectors land in the same neighborhood.

This is why traditional databases, however powerful, cannot replace vector search for the class of problems that require understanding.

How Approximate Nearest Neighbor Search Works - and Why "Approximate" Is Fine

When you search a vector database, your query is also converted into a vector. The database finds the stored vectors closest to yours - the "nearest neighbors." This tells you which stored items are most semantically similar to your query.

The catch: with millions of vectors, checking every single one would be slow. So vector databases use clever index structures (names like HNSW and IVF) that let them find approximately the nearest neighbors very quickly - without checking every row.

The "approximate" part rarely matters in practice. The difference between the truly closest result and the approximately closest result is usually imperceptible. You get search that is fast at scale and accurate enough for real applications. A database returning the 9th-most-similar document instead of the 8th causes no harm.

Real Use Cases

Semantic search: a legal team searches "early termination rights" and finds relevant clauses even if the documents say "exit provisions" or "cancellation terms."

Image similarity: an e-commerce site shows visually similar products when a user uploads a photo.

RAG (Retrieval-Augmented Generation): before an AI assistant answers a question, it retrieves the most relevant chunks from your knowledge base using vector similarity. This is what keeps AI grounded in specific company documents rather than hallucinating general answers.

Deduplication: find near-duplicate support tickets, product listings, or news articles even when they are worded differently.

When You Do Not Need a Dedicated Vector Database

Not every application needs a full vector database deployment. PostgreSQL with the pgvector extension handles vector search well for most teams - up to a few million vectors with reasonable query volume. If you are just starting out, or your vector collection is small, pgvector plus your existing database is the right starting point. Dedicated vector databases like Pinecone, Qdrant, or Weaviate become relevant when you are searching hundreds of millions of vectors or need specialized features like multi-tenant isolation or real-time index updates.

The general rule: reach for what you already have, and graduate to a dedicated solution when you outgrow it.

Common Misunderstandings

"Vector databases replace regular databases." They do not. They solve one specific problem - similarity search - and they are almost always used alongside a regular database, not instead of one.

"Better vectors = better database." The database is infrastructure. The quality of what you retrieve depends entirely on the quality of the embeddings you store. A great vector database with bad embeddings returns bad results.

"Approximate means inaccurate." In practice, approximate nearest neighbor search is accurate enough for every real use case. The "approximate" label is a technical precision, not a warning about quality.

What to Explore Next

• /posts/what-are-embeddings - what embeddings are and how models turn meaning into numbers
• /posts/rag-foundations-retrieval-quality - how vector search powers retrieval-augmented generation
• /posts/vector-databases-compared - a side-by-side look at pgvector, Pinecone, Qdrant, and Weaviate

Common Mistakes

Thinking a vector database replaces a relational database. Vector databases are optimized for approximate nearest-neighbor similarity search over embeddings - they are not designed for exact lookups, foreign key joins, ACID transactions, or aggregations. Most production systems use both: a relational database for structured metadata and a vector store for semantic retrieval.

Assuming any embedding model works for any retrieval task. Embeddings trained for text classification cluster semantically related documents by class label, which is different from clustering them by meaning for retrieval. Using a classification embedding for a RAG pipeline will produce poor retrieval results; you need embeddings trained specifically for retrieval tasks, such as those fine-tuned with contrastive loss on query-passage pairs.

Searching all vectors when metadata filtering could shrink the search space first. Running a nearest-neighbor query over millions of embeddings when you could first filter by user ID, date range, or document type wastes compute and degrades latency. Pre-filtering with metadata conditions before the vector search dramatically reduces the search space and improves both speed and relevance.