Vector search is a method of finding similar items by comparing their mathematical representations — called embeddings — instead of matching keywords. It converts text, images, or audio into lists of numbers, stores them in a vector database, and uses a similarity metric such as cosine similarity to return the closest matches. It is the retrieval engine behind semantic search, recommendation systems, and Retrieval-Augmented Generation (RAG).

Table of contents

1. What you need before starting

2. How vector search works, step by step

3. A real example with real numbers

4. Vector search vs keyword search vs hybrid search

5. How to choose your setup

6. Why it works: the algorithms underneath

7. Seven common mistakes

8. FAQ

What you need before starting

You do not need to be a mathematician. You need three things:

• A working idea of what a vector is. It is an array of numbers. [0.5, 1.2, -0.8] is a three-dimensional vector. A modern text embedding is the same thing with 384 to 3,072 numbers in it.

• Familiarity with databases. Vector search relies on a store that can hold and query these arrays quickly. If you have used a managed database, you already have the mental model.

• Optional: basic Python. Helpful for the code examples, not required to follow the concepts.

It also helps to know the difference between structured data (rows and columns, like a spreadsheet) and unstructured data (free-form text, images, audio). Vector search exists because keyword matching fails badly on unstructured data.

How vector search works, step by step

Step 1: Turn your data into embeddings

An embedding is a mathematical representation of an object — a word, a sentence, an image — placed in a high-dimensional space. Think of it as translating meaning into coordinates.

The word king becomes one vector. Queen becomes another. Those two sit close together in the space, while apple sits far away. That is not a coincidence: embedding models are trained on huge corpora specifically so that distance in the vector space corresponds to closeness in meaning.

Current models produce vectors of varying width. A 384-dimension model is fast and cheap. A 1,536-dimension model captures more nuance but costs more to store and query. You can generate embeddings through the NevTan Cloud embeddings API or compare available options in the model catalog.

Pro tip: Whatever model you pick, you must use the same model for indexing and for querying. Vectors from two different models are not comparable — this is the single most common beginner bug.

Step 2: Choose where the vectors live

A vector database stores, indexes, and queries vectors efficiently. Unlike a relational database doing exact matches, it uses approximate nearest neighbour (ANN) algorithms to find close vectors without scanning every row.

Your realistic options:

If you already run Postgres, you can create a database and add the vector extension. If you would rather skip the infrastructure entirely, NevTan Vector & RAG handles storage, indexing, and querying for you — see Vector & RAG pricing for the cost model.

Pro tip: Start managed. Self-hosting a vector index is a real operational commitment — replication, backups, index rebuilds. Do it once you know the workload, not before.

Step 3: Index your data

Indexing is the batch job that reads your content, chunks it, embeds each chunk, and writes the vectors to your store.

Take a catalog of 10,000 product descriptions. You run each through an embedding model and store the resulting vector alongside its metadata (product ID, category, price). For long documents, you split first: chunks of roughly 200–500 words, ideally broken on semantic boundaries like headings rather than a fixed character count.

Quality in, quality out. Strip HTML, normalise whitespace, drop boilerplate navigation text. Noisy input produces noisy embeddings, and no amount of tuning downstream fixes that. A practical walkthrough is in Create your first RAG collection, and the mechanics of storing and organising content are covered in the docs on collections and documents.

If your source content lives in Google Drive, Notion, or a repository, you can skip the custom pipeline and use connectors with scheduled syncs to keep the index current automatically.

Pro tip: Store a small overlap (roughly 10–15%) between adjacent chunks. It prevents an answer that straddles a chunk boundary from being cut in half.

Step 4: Run a query

At query time you embed the user's question with the same model, then ask the database for the nearest stored vectors.

The database scores candidates using a similarity metric — usually cosine similarity, which measures the angle between two vectors on a scale from -1 to 1. A score near 1 means near-identical meaning. It returns the top K results with their scores.

This is the whole point of semantic search: a query can match a document that shares zero keywords with it, because the meaning lines up. The full query API, including metadata filters and top-K settings, is documented under querying.

Pro tip: For a search box, K = 5–10. For a recommendation feed, K = 20–50 so you have a pool left after filtering. For RAG, keep K low (3–5) — stuffing an LLM prompt with weak matches degrades the answer.

Step 5: Integrate, filter, and measure

Now wrap it in an API endpoint: accept a query, embed it, search, filter, return.

Two things separate a demo from production:

Filtering. Vector similarity does not understand business rules. "Only show items in stock" or "only documents this user can read" must be enforced as a metadata filter, applied inside the query — not after the fact, or you will return fewer results than you promised.

Hybrid search. Combining vector similarity with keyword (BM25) scoring consistently beats either alone, especially for queries containing product codes, names, or exact identifiers, where pure semantic search is surprisingly weak.

Then measure. Track p95 latency and recall, and watch what users actually click. Monitoring AI inference performance covers the metrics worth alerting on, and you can wire it up with NevTan monitoring. When traffic grows, scaling on demand matters more than index tuning.

Pro tip: Log every query, the returned IDs, and which one the user clicked. That click log becomes your evaluation set — and eventually your re-ranking training data.

The results

Round-trip latency: ~50 ms, of which the embedding API call is the majority and the vector lookup is a few milliseconds.

Notice the top result. The article is titled Account Recovery and never uses the phrase "reset my password" in its heading. Keyword search ranks it low or misses it. Vector search puts it first, because the meanings overlap.

Rough monthly cost at this scale: one-time embedding of 15,000 chunks is cents, not dollars. Ongoing cost is dominated by query-time embeddings and storage. See inference pricing for current rates.

Vector search vs keyword search vs hybrid search

The honest verdict: hybrid wins for most production search. Pure vector search is the right call for RAG pipelines and recommendations, where you want conceptual proximity rather than literal matching.

How to choose your setup

Prototyping or under 1M vectors → pgvector on a Postgres instance you already run. Nothing new to learn, nothing new to pay for.

Production, millions of vectors, sub-100ms requirement → a dedicated vector database with horizontal scaling and a tuned HNSW index.

Building RAG for a chatbot or agent → pick retrieval that integrates cleanly with your orchestration layer and your model provider. If you are routing between models, an AI gateway sitting in front of retrieval keeps provider swaps from becoming rewrites. For the architectural difference this makes, see AI agents vs traditional chatbots.

Considering fine-tuning instead → usually the wrong instinct. Retrieval adds knowledge; fine-tuning adjusts behaviour and style. When to fine-tune vs prompt engineering unpacks the decision, and fine-tuning overview covers the mechanics if you decide you need both.

Team factor → if your engineers live in Python and are comfortable operating infrastructure, open-source options are viable. If not, managed is cheaper once you count engineering hours.

Why it works: the algorithms underneath

Vector search operates on semantic meaning rather than literal form, and two ideas make that practical.

Embedding models map meaning to geometry. Trained on enormous corpora, they place car near vehicle and far from food. Distance becomes a proxy for relatedness.

ANN indexes make search fast. Comparing a query against every stored vector is a brute-force linear scan — accurate but slow. Instead, indexes like HNSW (Hierarchical Navigable Small World) build a navigable graph, and IVF (Inverted File Index) partitions vectors into clusters. Either way, the search jumps to the promising region of the space instead of touring the whole thing.

The trade is explicit: a sliver of accuracy for a large gain in speed. Searching 10 million vectors might take ~100 ms brute-force and ~5 ms with HNSW, while holding 95–99% recall. That ratio is what makes vector search viable inside a search bar, a recommendation widget, or an AI agent that has to answer in real time.

Seven common mistakes

1. Using a mismatched or outdated embedding model. A general-purpose model on medical text or source code underperforms badly. Evaluate on your data, not on a public leaderboard.

2. Using different models for indexing and querying. The vectors are not in the same space. Results will look random and you will waste a day debugging the database.

3. Skipping preprocessing. HTML tags, navigation boilerplate, and inconsistent casing all end up encoded into your vectors. Clean first.

4. Chunking badly. Fixed 1,000-character chunks that slice sentences in half destroy meaning. Chunk on semantic boundaries with slight overlap.

5. Picking the wrong similarity metric. Cosine is the default, but for normalised vectors dot product is equivalent and faster; some workloads want Euclidean distance. Check what your model was trained for.

6. Leaving the ANN index on defaults. HNSW's M and efConstruction need benchmarking against your data size and query pattern. Defaults give you either slow queries or poor recall.

7. Treating filtering as an afterthought. Access control especially: if a metadata filter is applied after retrieval, you can leak the existence of documents a user should never see. See protecting AI APIs and endpoints and the docs on API keys.

FAQ

What is the difference between vector search and keyword search?

Keyword search matches the literal words you typed. Search "car repair" and it returns documents containing those words. Vector search converts both query and documents into embeddings and compares meaning, so it can return a document about "automobile maintenance" even with no word overlap.

What are embeddings in simple terms?

An embedding is an object — a word, sentence, or image — turned into a list of numbers by a model that has learned what things mean. Objects with similar meanings get similar lists, which places them close together in a multi-dimensional space.

What is a vector database?

A database built to store and query vectors efficiently, using indexes like HNSW or IVF to find the nearest matches among millions of entries in milliseconds. It is the core infrastructure for any vector search or RAG application.

What is cosine similarity?

A metric that measures the cosine of the angle between two vectors. A score of 1 means they point the same direction (very similar), 0 means they are unrelated, and -1 means opposite. It is the most common metric in vector search because it ignores vector magnitude and compares direction only.

What is RAG (Retrieval-Augmented Generation)?

RAG improves LLM accuracy by retrieving relevant documents from a knowledge base and inserting them into the prompt before the model answers. It reduces hallucination and lets a model use private or recent data it was never trained on. Full explanation in RAG: Retrieval-Augmented Generation.

How much data do I need for vector search?

There is no minimum. A few hundred items works fine with a pre-trained embedding model — you are not training anything. The advantage over keyword search grows as your corpus grows and as queries get more conversational.

Is vector search expensive to run?

Three cost lines: embedding generation (per token, one-time for indexing plus per query), vector storage (per million vectors per month), and compute for queries. Small projects run for a few dollars a month. Costs scale with query volume more than with corpus size, because ANN indexes are cheap to search. Compare Vector & RAG pricing and inference pricing.

Can I use vector search for images and audio?

Yes. Any modality with an embedding model works the same way — multimodal models even place images and their text descriptions in a shared space, so you can search photos with a written query.

Does vector search replace my existing search engine?

Rarely. Most production systems run hybrid: keyword search for precision on names and identifiers, vector search for meaning, then a re-ranking step to merge the two result sets.

How do I keep the index fresh when content changes?

Re-embed changed documents on a schedule or on a webhook trigger. Managed syncs and webhooks handle this without a cron job you have to babysit.

Build it on NevTan Cloud

Vector search needs three pieces of infrastructure working together: somewhere to generate embeddings, somewhere to store and query them, and somewhere to run the application in front of both.

NevTan Cloud gives you all three. Generate vectors through the embeddings API, store and query them with Vector & RAG, and ship the app itself straight from your repository — deploy from Git with automatic deployments on every push, then scale it as query volume grows.

Start here: Quickstart guide · View pricing · Why NevTan