When to use vector search — and when not to

Most database questions have a right answer that everyone agrees on. "What's the balance of account 4471?" There's one number. "Which orders shipped yesterday?" There's an exact list. You could check the answer by hand and either it's correct or it isn't.

Vector search is for the other kind of question. "Which of these support tickets are basically the same complaint?" "What photos in my library look like this one?" "Show me products similar to the one I'm looking at." There's no single right answer to sort by — there's a sense of closeness, of "these belong together," and reasonable people might rank the results a little differently.

If you can tell those two kinds of questions apart, you already know most of what you need to decide whether vector search is the right tool. This page is about drawing that line clearly, with examples on both sides, so you don't reach for a vector database when a plain lookup would do — or grind away at keyword matching when the thing you actually want is meaning.

The one-sentence version

Vector search is the right tool when you're looking for things that are similar in meaning, not identical in content.

Everything below is a longer way of saying that.

A quick analogy

Imagine two ways to find a book in a library.

The first is the card catalog. You know the exact title, or the exact call number, and you go straight to it. Fast, precise, and useless if you don't already know what you're looking for. That's a regular database index: give it the exact key, it gives you the exact row.

The second is walking up to a good librarian and saying "I want something like The Martian — stranded, resourceful, funny, lots of real science." The librarian doesn't need any of your words to appear in the book's title. They understand what you mean and hand you three novels that feel like that. That's vector search: you describe the shape of what you want, and it finds things that are close to that shape, even when none of the words match.

Both are useful. You wouldn't fire the librarian because the card catalog is faster, and you wouldn't throw out the card catalog because the librarian is smarter. They answer different questions.

Two ways to find a book. On the left, a card catalog: you know the exact title, and one straight arrow leads to the single exact book. On the right, asking a librarian for "something like The Martian": arrows fan out to three different books that feel similar. One needs the exact key; the other understands what you mean.

When vector search is the right tool

These are the questions vector search was built for. The common thread: you want things that are alike, and "alike" can't be captured by an exact match on a word or a number.

Semantic search over text. "Find documents about renewable energy" should return the article about wind farms even though it never says "renewable." Searching help docs, legal contracts, research papers, product catalogs, past support tickets — anywhere the same idea gets written a dozen different ways.
Recommendations. "People who liked these three things might also like…" You take what someone already engaged with and look for nearby items. No one has to hand-tag "similar products"; the vectors already know what's close.
Image, audio, and video similarity. "Find photos that look like this one." "Find songs with this vibe." Pixels and waveforms don't keyword-match, but their embeddings sit near each other when the content is alike.
Deduplication and clustering. "Are these two customer complaints really the same issue in different words?" Near-duplicate detection and grouping-by-theme are similarity questions at heart.
Retrieval for AI assistants (RAG). When a chatbot needs to pull the most relevant paragraphs from your knowledge base to answer a question, it's doing vector search under the hood: find the passages closest in meaning to what the user asked.

If your question sounds like "find things like this" or "group these by what they're about," you're in the right place.

When vector search is the wrong tool

This is the half people skip, and it's the more useful half. Vector search is genuinely bad at some things — not slow-but-workable, actually the wrong shape. Reaching for it here means more cost, more complexity, and worse answers than the boring tool would have given you.

Exact lookups. "Get the user with id = 4471." "Fetch order #88231." You know the exact key and you want that exact record. A regular database finds it instantly and correctly. Vector search would give you the nearest record — which is a bizarre thing to want when you already know precisely which one you need.
Filtering on precise values. "All invoices over $500 from last March." "Every user in Canada with an active subscription." These are exact conditions on structured fields — a job for WHERE clauses in SQL, not similarity. (Vector Panda lets you attach filters like these to a similarity search to narrow it down, but the filtering itself isn't the vector part.)
Counting, summing, and reporting. "How many orders shipped yesterday?" "What's total revenue by region?" Aggregation is arithmetic over exact rows. There's nothing fuzzy to compare; a vector database is the wrong building.
Answers that must be provably complete or exact. Anything where "we found the approximately closest matches" isn't acceptable — regulatory lookups, financial reconciliation, "did this specific transaction happen." Vector search trades a little exactness for speed and meaning; if you can't spend that exactness, don't.
Keyword-precise search. Sometimes you really do want the literal word. Error codes, part numbers, function names, legal citations, a person's exact surname — cases where "close in meaning" is a distraction and you want the string, character for character. A keyword index (or a plain LIKE) beats embeddings here.
Tiny datasets. If you have forty items, you don't need a vector database. You can compare against all forty in memory in the time it takes to read this sentence. Vector infrastructure earns its keep at thousands to billions of items, not dozens.

The pattern across all of these: you already know the exact thing you want, or the answer has to be exact, or there's simply nothing "fuzzy" to compare. When the question has a single provably-correct answer, the plain tool is the right tool.

The middle ground: use both

Plenty of real systems aren't one or the other. A good product search does keyword matching and semantic matching, then blends the results — the literal word "waterproof" from keyword search, plus "rain jacket" and "dry bag" from vector search, ranked together. This is usually called hybrid search, and it exists precisely because neither half is complete on its own.

Likewise, most vector searches in production are filtered: "find products similar to this one, but only in the Electronics category, and in stock." The similarity is the vector part; the category and stock checks are ordinary exact conditions riding along. You don't have to choose one worldview — you narrow with exact filters and rank with similarity, in the same query.

So "when to use vector search" is rarely all-or-nothing. The real skill is spotting which part of your question is a similarity question and pointing vectors at that part only.

A three-question gut check

When you're not sure, ask:

Do I already know the exact record I want? If yes — a key, an ID, an exact field value — use a regular lookup. Vector search is for when you can't name the exact thing, only describe it.
Would two sensible people rank the results slightly differently? If yes, you're in similarity territory, and that's a good sign for vectors. If there's one indisputable correct answer, you're not.
Does "close enough, ranked by relevance" satisfy the requirement? Vector search returns the approximately nearest matches, fast. If your task can't tolerate "approximately," reach for the exact tool instead.

Two or three yeses that point the same way and the decision usually makes itself.

A three-question gut check. One: do I already know the exact record I want? If so, use a regular lookup. Two: would two sensible people rank the results differently? If so, it's a similarity problem, which is good for vectors. Three: is "close enough, ranked by relevance" good enough? If so, vector search fits. When two or three of the answers point the same way, the decision makes itself.

Closing

Vector search is a genuinely new capability — for the first time, "find me things that mean something similar" is a query you can run at scale. That's worth getting excited about. It's also not a replacement for the database you already have; it's a second kind of question you can now ask, sitting next to the exact-match questions you've always been able to ask.

Get the fit right and it feels like magic. Force it onto an exact-lookup problem and it feels broken — because it is, for that job.

Once you've decided your problem is a similarity problem, the next question is how the numbers work — how a paragraph or an image turns into a vector in the first place. That's Vector embeddings 101. Or, if you'd rather just see it run, pick one of the Projects and build something end to end.