What Is a Vector Database? How It Works and When You Need One 2026

A customer types “my parcel never showed up” into your help search. It shows them gift cards.

A vector database fixes that. It stores text as embeddings, lists of numbers that capture meaning, and finds the closest match even when no words overlap. You need one for semantic search, RAG chatbots and recommendations. For a small app, Postgres with pgvector is enough.

We ran nine customer questions through both. Vector search got 7 right. Keyword search got 3.

Its two misses show the catch nobody mentions.

What is a vector database, in plain English?

A vector database stores data as vectors and finds the ones closest to a query. Closeness stands in for similarity of meaning.

Think of a map where every sentence gets a spot. Sentences about the same idea land close together, so “how do I get my money back” sits beside “refunds go to the original payment method.” No useful word is shared.

That spot is the embedding. An embedding model turns text into a fixed-length list of numbers; our generative AI explainer covers how these models learn. The one we tested outputs 384 numbers per sentence. OpenAI’s text-embedding-3-small outputs 1,536.

How does a vector database work?

It works in four steps: split your data, embed it, store the vectors, then find each query’s nearest neighbours.

Cosine, dot product or Euclidean: which distance should you use?

Use whatever your embedding model was built for. For most text models, that’s cosine similarity.

Pick the wrong one and results still come back, just ranked worse. Nobody notices.

Why it doesn’t check every vector: HNSW and IVF

Checking every stored vector is exact but slow at scale. So vector databases build an index that checks a small, promising slice instead.

HNSW links vectors into a layered graph and hops toward the query. IVF groups vectors into clusters and searches only the nearest few. Both trade a little accuracy for a lot of speed.

How little accuracy? We embedded 19,341 real sentences and searched them with 200 held-out ones, on a single CPU core:

HNSW at its default was 15 times faster and still found 97 of every 100 true matches. IVF was quicker still at small settings but missed far more, even at 10 clusters searched.

Now look at the exact row. Under a millisecond for nearly 20,000 vectors means a small app needs no index at all. Scaled up, a million vectors would take about 50 ms per query, roughly where an index starts to pay. We didn’t run a million-vector test.

Keyword search vs vector search: what our test showed

Vector search found the right help article for 7 of 9 queries. Keyword search found 3.

We wrote 12 help-centre articles for an imaginary clothing shop and typed nine questions like a fed-up customer. Keyword search used SQLite’s full-text engine with BM25 ranking, minus common words. Vector search used Chroma 1.5.9 with its default all-MiniLM-L6-v2 model and cosine distance.

import chromadb

client = chromadb.EphemeralClient()
docs = client.create_collection("help", configuration={"hnsw": {"space": "cosine"}})
docs.add(
    ids=["refunds", "returns"],
    documents=[
        "Refunds go to the original payment method within five to ten days.",
        "You can send back unworn items within 30 days.",
    ],
)
hit = docs.query(query_texts=["how do I get my money back"], n_results=1)
print(hit["ids"][0], 1 - hit["distances"][0][0])  # best match and its similarity

Chroma fetched its 79 MB model on the first run, then answered offline. The full test ran the same code on all 12 articles:

Keyword search failed as expected. It grabbed a stray shared word, or found nothing because the customer said “receipt” and the article said “invoice.”

The vector misses are the interesting part.

“The jacket came torn” went to the jacket page, not the damaged-items policy. The embedding latched onto the product. Meaning search is fuzzy, and fuzzy is sometimes wrong.

“SKU-9902” is worse. That product doesn’t exist, yet vector search still returned the jacket, with a similarity of 0.32. The real code, SKU-4471, scored 0.33. A vector database always hands back its nearest neighbour, and no score threshold could split those two.

Our take: Use both. Hybrid search runs keyword and vector search together, so exact codes, names and error messages still match exactly. Then test 20 real customer questions before you trust the scores.

This was one small model on 12 English articles. A bigger model might fix the jacket query; we didn’t try one. No model says “no match” by itself.

Vector database vs traditional database: do you need a new one?

Usually not at first. A vector database adds similarity search; it doesn’t replace the one holding your orders and users.

pgvector turns Postgres into a vector store. It searches exactly by default and adds HNSW or IVFFlat indexes when you need speed. Indexes cover up to 2,000 dimensions. Your vectors live next to your rows, so one query can filter by customer and rank by meaning.

Here’s our cosine search in Postgres. <=> is pgvector’s cosine distance operator, and $1 is the query’s embedding:

CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE help_docs (id text PRIMARY KEY, body text, embedding vector(384));
CREATE INDEX ON help_docs USING hnsw (embedding vector_cosine_ops);

SELECT id, 1 - (embedding <=> $1) AS similarity
FROM help_docs
ORDER BY embedding <=> $1
LIMIT 3;

We didn’t run this on a live Postgres for this post. The syntax follows pgvector’s own documentation. Want to try it without installing anything? Managed Postgres on DigitalOcean supports the vector extension on versions 14 to 17.

Heads-up: the DigitalOcean and n8n links on this page are affiliate links. We may earn a commission if you buy, and your price stays the same.

Which vector database should you pick?

Start with what you already run. Move to a dedicated engine when vector search is the product, not a feature.

We checked every price on 15 November 2026. One trap: Supabase pauses free projects after a week without activity, so don’t demo a client app on it.

Running the open-source versions yourself? A small virtual private server handles Qdrant or Chroma for a side project. Watch the memory, because HNSW indexes want to live in RAM.

Best for / not ideal for: Pinecone suits a team that wants search live this week with no servers to patch. It’s a poor fit when vectors must sit beside your app’s rows, because every query then spans two systems. That’s pgvector’s home turf.

How much space do your vectors actually take?

Each pgvector vector takes 4 bytes per dimension plus 8. Dimensions, not document length, decide the bill.

Apply that to the free tiers. Supabase’s 500 MB holds about 81,000 vectors at 1,536 dimensions, before the index and your other tables take their share. Pinecone’s 2 GB Starter fits roughly 325,000 before metadata.

A 500-page help centre cut into 2,000 chunks fits any free tier easily. A store with 50,000 products at three chunks each needs about 920 MB at 1,536 dimensions. That’s past Supabase’s free plan. At 384 dimensions it drops to 230 MB, if search quality survives the cut.

When do you actually need a vector database?

You need one when people search by meaning and your data outgrows a list in memory.

• A chatbot on your own docs: yes, because retrieval is the whole trick. Our RAG explainer shows where the vector store sits. The RAG chatbot tutorial builds one in n8n with no code.
• A few thousand chunks: start with pgvector or even a NumPy array. You won’t need an index yet.
• Thousands of products: use hybrid search, because customers type both “warm hiking jacket” and exact SKUs.
• Agent memory: a vector store lets an AI agent in n8n recall past notes by topic. Prune it often.
• Codes, names and filters only: skip it. A normal index matches those exactly and never invents a near miss.

Frequently asked questions

The bottom line

So, what is a vector database? It’s storage that finds the closest meaning instead of the exact words. In our test that turned 3 right answers into 7.

For most sites, pgvector in the Postgres you already run is the right first step. Move to Pinecone or Qdrant once your vectors run into the millions. Whatever you pick, pair it with keyword search. Semantic search always returns something, even for a product that doesn’t exist.

Next step: write down 20 questions your users really ask. Run them through a free tier and count how many come back right.