Reviewed: July 2026
Every "chat with your documents" feature, every AI assistant that answers from a company's own knowledge, every semantic product search — underneath nearly all of them sits the same mechanism. Vector search finds things by meaning instead of by matching words, and it has quietly become the connective tissue between databases and AI. Understanding it is no longer optional for data people, and it is more approachable than the jargon suggests.
What problem does vector search solve?
Traditional search matches words. That works until people phrase the same idea differently — a user searching "reset my password" never finds the document titled "account recovery procedure," because no significant words overlap. For decades the workaround was human effort: synonym lists, tagging, carefully chosen titles.
Vector search removes the workaround by comparing meanings. The question and the documents are both converted into a mathematical representation where similar meanings sit near each other, and search becomes a geometry problem: find whatever is closest.
What is an embedding, actually?
An embedding is a list of numbers — often hundreds or thousands of them — produced by a machine-learning model trained so that semantically similar inputs come out numerically close together. Think of it as coordinates in a space with very many dimensions: "password reset" and "account recovery" land near each other; "quarterly revenue" lands far away.
The practical pipeline is short:
- Split your content into sensible pieces (chunking)
- Run each piece through an embedding model, store the resulting vectors
- At query time, embed the user's question the same way
- Find the stored vectors nearest to the query vector — the nearest neighbours — and return their content
Definition — nearest-neighbour search: finding the stored vectors closest to a query vector. Doing this exactly over millions of vectors is slow, so databases build approximate indexes that trade a sliver of accuracy for enormous speed. Managing that trade-off is the heart of running vector search well.
Where does the database come in?
Somewhere, those vectors have to live, be indexed, and answer queries fast — alongside the ordinary data they describe. That "somewhere" is the interesting career fact: general-purpose databases absorbed the workload. PostgreSQL handles it through its vector extension ecosystem; MongoDB ships vector search natively. Dedicated vector databases exist, but keeping embeddings next to operational data — one system, one security model, no synchronisation pipeline — has become the common default for application teams.
For anyone with database skills, this is new demand landing on familiar ground:
| Classic database skill | Its vector-search equivalent |
|---|---|
| Index selection and tuning | Vector index types and build parameters |
| Query performance analysis | Recall-versus-latency tuning |
| Storage and memory planning | Quantisation — smaller vectors, less memory |
| Hybrid query design | Combining keyword and semantic results |
The same judgment, pointed at a new workload — which is why our PostgreSQL Administration and MongoDB Administration courses both give vector workloads real teaching time rather than a closing mention.
Building an AI feature and unsure where retrieval fits? Talk it through with someone who teaches this daily. Book a demo session
Why is vector search the heart of RAG?
Retrieval-augmented generation — RAG — is the standard architecture for making language models answer from your information instead of their training data. The flow: retrieve the most relevant content for a question, then hand it to the model as grounding for the answer.
Vector search is that retrieval step, and it is where RAG systems succeed or fail. A language model given the wrong passages will answer fluently and wrongly — fluent wrongness being the most dangerous failure mode software has ever shipped — and no amount of model quality repairs bad retrieval. Which means the unglamorous work — chunking strategy, embedding choices, index tuning, evaluating whether retrieval actually returns the right things — matters more than the model call that gets the attention. Teams discover this in production, usually the hard way.
Hybrid search is the maturing answer to vector search's own weakness: meanings are fuzzy, but product codes, names and exact phrases are not. Running keyword and vector search together and merging results gets the precision of one and the flexibility of the other.
What goes wrong in real vector-search systems?
The failure modes are worth knowing before you build, because they are predictable and almost never mentioned in introductory material.
Bad chunking poisons everything downstream. Split documents mid-thought and every retrieved passage arrives missing its context; split them too large and the embedding averages several topics into mush. Chunking is an editorial decision wearing a technical costume, and it deserves actual thought about how the content is structured and how people will ask about it.
Nobody evaluates retrieval. Teams assemble the pipeline, see plausible answers, and ship — without ever building a test set of real questions with known correct sources. Then quality complaints arrive and there is no instrument to diagnose them with. A few dozen question-to-source pairs, checked whenever anything changes, is the cheapest insurance in the field.
The index is tuned by default. Approximate indexes trade recall for speed through parameters someone is supposed to choose. Left at defaults, systems quietly return worse neighbours than they could — and because the answers are still fluent, nobody notices without that evaluation set from the previous paragraph.
Stale embeddings drift from reality. Content gets edited; embeddings made from the old version keep matching old meanings. Re-embedding on change is plumbing that has to exist, and it is precisely the kind of operational discipline database people already know how to build.
None of these are exotic. They are the ordinary difference between a demo and a system — a demo needs the pipeline to work once, on stage; a system needs it to keep working as content changes, volume grows and nobody is watching. Closing that gap is the actual job, and it is why this skill set is hired rather than improvised.
What should you learn, based on where you stand?
Application and AI engineers need the pipeline side: embedding models, chunking, retrieval evaluation, and the architecture around it. That is core material in our Generative AI & LLM Engineering course, and AI Agent Development builds on it — agents that retrieve badly act badly.
Data and database people need the operating side: vector index behaviour, memory and quantisation trade-offs, hybrid query design, and running the converged workload safely next to production data. Either database course above covers this from its engine's side.
Deciding between those two roles? Our comparison of AI engineer, ML engineer and data scientist paths maps the territory.
The takeaway
Vector search is not a fad bolted onto databases — it is search catching up with how people actually ask questions, and it has pulled databases into the centre of AI application architecture. The concepts fit in one article; the competence lives in operating it: indexes tuned against real recall targets, retrieval evaluated against real questions, memory budgets that survive real growth.
That operating depth is exactly what we teach — from the AI side in Generative AI & LLM Engineering, from the data side in PostgreSQL Administration and MongoDB Administration. Book a demo session if you want help choosing the entry point for your background.