What Is a Vector Database?

What is a vector database? It is a database built to store embeddings and search them by similarity. An embedding is a list of numbers that an AI model makes from a piece of text, an image or a sound, and the numbers capture the meaning of that item. Items with similar meanings get similar numbers, so the database answers a question by finding the stored items whose numbers sit closest to the numbers of your question. Those closest matches are called the nearest neighbors.

That sounds abstract, so picture a help center search box. A customer types “how do I get my money back on a yearly plan?” A keyword search hunts for those exact words and misses the right page, which says “Refund policy for annual plans.” A vector search finds it anyway, because the two texts mean nearly the same thing and their embeddings sit close together. This meaning-first lookup is why vector databases spread so fast with chatbots and AI search. The models behind it come from the field our guide to natural language processing explains, and they changed what a database query can ask.

First, the embedding: meaning turned into numbers

The answer to what is a vector database starts with the embedding, because the database only stores what the embedding model produces. An embedding model is a neural network trained on huge amounts of text, images or audio. You feed it a chunk of content, and it returns a vector: a list of numbers, often hundreds or thousands of them. Each number is one coordinate, a position on a scale the model learned during training. No single number carries a neat human label. The pattern across all of them, taken together, encodes what the content is about.

Training arranges the space so that related items land near each other. A sentence about refund windows sits near other sentences about refunds and billing, and far from a page about printer setup. The model never sees a rule that says refunds relate to billing. It learns the closeness from context, from the company words keep in real text. That learned closeness is the whole trick: once meaning becomes position, a computer can search meaning with arithmetic.

One rule matters here. The same embedding model must process the stored content and the incoming question. Two different models lay out two different spaces, and distances across spaces mean nothing. Teams treat the choice of embedding model as part of the database design, and they re-embed their whole collection if they ever switch models.

What the database stores, and how one search runs

A vector database never stores the bare vector alone. Each record holds the vector, an ID, a reference back to the original item, and metadata: the title, the source, the date, the product or category it belongs to. That metadata does real work. It lets a search stay inside one product manual, one language or one customer’s documents, instead of roaming the whole collection. Managed systems such as Pinecone build their service around exactly this bundle of vector, ID, metadata filtering and updates, and Pinecone’s documentation describes the same embed, store and query flow this article follows.

A search then runs in four steps. The app sends your question through the same embedding model, which turns it into a query vector. The database compares that vector against its stored vectors using a distance measure. It ranks the results by closeness and returns the top few, usually called the top K. Your app receives the matching passages, products or photos, not the raw numbers, and shows them or hands them to a chatbot.

The distance measure decides what “close” means. Cosine similarity compares the angle between two vectors, so it cares about direction and not length. Euclidean distance measures the straight-line gap between two points. Dot product mixes angle and length into one score. A database like pgvector offers all three, and the right choice depends on how the embedding model was trained. Pick the measure the model expects, or the ranking quietly degrades.

Why exact search breaks, and how a vector index fixes it

The honest way to find the nearest neighbors is exact search: compare the query vector with every stored vector and keep the closest. That works for a few thousand items. It falls apart at scale, because every single comparison costs arithmetic across hundreds or thousands of numbers, and a busy app may hold millions of vectors and answer many searches per second. The math bill grows faster than the hardware budget.

So vector databases settle for approximate nearest neighbor search, shortened to ANN. An ANN index skips most of the collection and returns neighbors that are almost certainly the true closest ones. The share of true neighbors an index actually finds is called recall. A tuned index gives up a sliver of recall and gains a huge amount of speed, and for search boxes and chatbots that trade is nearly always worth it. In what is a vector database, the index is not a detail bolted on at the end. The index is the product.

The index most systems reach for is HNSW, short for Hierarchical Navigable Small World. Yu. A. Malkov and D. A. Yashunin published the HNSW paper on arXiv in 2016, and its design reads like a map of shortcuts. The index links every stored vector to its nearby vectors, building a graph. It then stacks copies of that graph in layers. The bottom layer holds every point, joined by short links to its closest neighbors. Higher layers hold fewer and fewer points, joined by longer links that jump across the map. A search starts at the top, rides the long links toward the question’s neighborhood, drops a layer, and repeats, finishing with a short walk among close points at the bottom. Because each layer narrows the area to check, the search grows slowly even as the collection grows, a pattern the paper describes as logarithmic scaling.

The other common design is IVF, short for inverted file. IVF sorts the stored vectors into groups, often called buckets or lists, each gathered around a center point. A search compares the query against the centers first, then checks only the nearest few buckets in full. Probing more buckets raises recall and costs time, so the setting becomes a dial between speed and accuracy. The pgvector project on GitHub documents both designs for Postgres: it calls the IVF groups lists, and it supports HNSW as the other index type. Neither index wins everywhere. HNSW usually answers faster and uses more memory, while IVF builds quickly and stays lean. Teams pick based on their collection size and query load, then tune.

Vector database vs a traditional database

The two kinds of database answer different questions. A traditional database stores exact values and retrieves exact matches. A vector database stores embeddings and retrieves close matches. Neither replaces the other, and most real systems run both side by side.

Notice what the vector side gives up. It cannot promise the one true answer, only the closest ones it found. It also cannot add a column of prices or settle a payment. Ask it for every order over 500 dollars and it has nothing to say. Similarity is a new power, not a replacement for exact records.

What teams actually use them for

What is a vector database for, in practice? Four jobs account for most of the real deployments.

The biggest is RAG, short for retrieval-augmented generation, the pattern behind company chatbots. The team embeds its manuals, policies and help pages in advance. When a user asks a question, the database retrieves the closest passages, and the language model writes its answer from those passages instead of from memory alone. Answers get sources, and companies can update facts by updating documents. Teams that let the agent search, check its own results and try again run the extended pattern our guide to agentic RAG walks through.

Semantic search is the second job: search boxes that match meaning instead of words, across help centers, document libraries and product catalogs. Recommendations are the third: a store or streaming app embeds products and viewing history, then suggests whatever sits near what a person already likes. The fourth job is image and duplicate search. Support teams find near-identical tickets, photo apps group near-duplicate shots, and marketplaces spot listings that reuse the same picture, all by comparing image embeddings.

A vector database example, end to end

Put the pieces together on the help center from earlier. On setup day, the team splits its help pages into short chunks, runs each chunk through an embedding model, and stores every vector with its page title and link. That takes minutes of compute and happens once. From then on, the collection just sits there, indexed and ready.

A customer asks how to get money back on a yearly plan. The app embeds the question with the same model, the index walks to the right neighborhood, and the database returns the refund policy chunk first, a billing page second, and weaker matches after that. The app shows those pages, or feeds the top chunks to a chatbot that drafts the reply. No one typed the word refund, and the right page still won.

You may not need a separate one: the pgvector route

Here is the honest note most explainers bury. Many teams never adopt a dedicated vector database at all. They add vectors to the database they already run. The clearest case is pgvector, an open source extension that gives Postgres a vector type, distance operators for the L2, inner product and cosine measures, and both HNSW and IVF indexes. Vectors then live in the same tables as the rest of the app, with the transactions, backups and joins Postgres already provides. The same Postgres that runs patterns like multitenant database containers for hosted apps can hold each tenant’s embeddings too.

Dedicated systems still earn their place. Pinecone sells a fully managed service, so the team runs no database servers at all. Weaviate, Milvus and Qdrant focus on very large collections and heavy query traffic, with features built for that scale. The sensible path for most teams is boring: start with pgvector if Postgres already holds your data and your collection is modest, measure, and move to a dedicated vector database when size or query load proves you need one.

Conclusion

So what is a vector database, in the end? It is a database that stores embeddings, the number lists that capture meaning, and finds the stored items closest to your question. Embeddings supply the meaning, the ANN index supplies the speed, and metadata keeps the search inside the right corner of the collection. That trio powers chatbot retrieval, semantic search, recommendations and image search. And the idea stays flexible: it can live in a dedicated service built for billions of vectors, or in a small extension inside the Postgres you already run.