Vector Databases Explained for Business Leaders

Search that understands what you meant

A customer types 'my boiler is making a banging noise' into a support portal. The help article that answers it is titled 'Kettling in combination boilers'. No words in common, so a traditional keyword search returns nothing useful.

Vector search finds it anyway. It compares meaning rather than spelling, and that is the whole reason vector databases have gone from a niche research tool to something every AI vendor mentions. Understanding what they do, and do not do, will save you from both overbuying and underestimating the work involved.

How it works, without the maths

An AI model called an embedding model reads a piece of text, or looks at an image, and turns it into a long list of numbers. That list is a kind of fingerprint of the meaning. Items about similar things get similar fingerprints, even when they use completely different words.

A vector database stores those fingerprints and, when a question comes in, turns the question into a fingerprint too and finds the closest matches very quickly, even among millions of items. That is it. The database does not understand anything itself; it is very good at finding near neighbours.

A vector database finds things that are similar. It does not know whether they are correct, current or allowed to be shown.

Where businesses genuinely use it

• AI assistants that answer from your own documents. The system finds the relevant policy or manual sections, then an AI model writes an answer from them. This is often called retrieval-augmented generation.
• Better site and internal search. Finding products, help articles or past tickets when people describe things in their own words.
• Similar item recommendations. 'Customers viewing this also looked at' based on product descriptions and images, useful when purchase history is thin.
• Finding duplicates. Spotting near-identical supplier records, support tickets or CVs.
• Matching. Pairing job descriptions with candidates, or enquiries with the right specialist.

The first of these is by far the most common reason businesses come to us asking about vector databases. We cover the approach in grounding AI in your own data.

Do you need a separate vector database?

Often, no. PostgreSQL, which many business applications already run on, has an extension called pgvector that adds vector search. For hundreds of thousands, and often a few million, items, it performs well and keeps your data, permissions and backups in one place.

Dedicated vector databases earn their place at larger scale, with very high query volumes, or when you need features such as advanced filtering at speed or managed hosting that scales automatically.

For a named product comparison, see our vector database comparison.

What goes wrong in practice

The database is rarely the problem. The problems are almost always in what goes into it and how results are used.

1. Poor chunking. Documents split into pieces that cut answers in half, so the right information is never retrieved whole.
2. Stale content. Policies updated in the source system but not re-indexed, so the assistant confidently quotes last year's version.
3. Ignored permissions. A staff assistant retrieving HR documents the person asking should never see.
4. Exact terms missed. Vector search is weak on part numbers, product codes and names, so pure vector search frustrates people. Combining it with keyword search, known as hybrid search, fixes most of this.
5. No evaluation. Nobody measures whether the right items come back, so quality slowly drifts.

What it costs

For a small or medium business, the vector database is usually a minor cost, especially using pgvector on an existing server. The larger costs are creating embeddings for your content, which is modest for most document collections, and the engineering to keep the index current, respect permissions and test result quality.

Changing embedding model later means re-processing everything, so it is worth choosing carefully and storing the original text alongside the vectors. Budget time for building a set of real test questions with known correct answers; without it you cannot tell whether a change made things better or worse.

Questions to ask before you commit

• What exactly do people need to find, and how do they search for it today?
• How many items, and how often do they change?
• Do different users have different permissions on the content?
• Do searches include codes, names or numbers that must match exactly?
• Can our current database handle this with an extension?
• How will we measure whether results are good?

At SpiderHunts we answer these before recommending any particular technology, and most of the time the answer is a hybrid search on infrastructure the client already has. If you are planning a document assistant or smarter search, our AI integration service covers the full build, including the unglamorous parts that decide whether it works.

Frequently asked questions