Vector databases and embeddings

The newest family, and the one behind the current wave of AI features. A vector database stores lists of numbers — embeddings — and answers a question the others cannot: "what is most similar in meaning to this?" Pinecone, Weaviate, Qdrant, Milvus and Postgres's pgvector extension are the names; this lesson is what the family is for and, as ever, when you actually need one.

The problem: searching by meaning, not by words

The search lesson matched words. But "how do I reset my password" and "I forgot my login credentials" share almost no words and mean nearly the same thing. Keyword search — even good full-text search — misses that, because it matches tokens, not meaning.

Semantic search matches meaning. The enabling trick is the embedding: an AI model turns a piece of text (or an image, or audio) into a list of numbers — a vector, typically hundreds to a couple of thousand dimensions — positioned so that things with similar meaning have vectors close together in that space.

"reset my password"          → [0.02, -0.15, 0.88, ...]   (1536 numbers)
"forgot my login"            → [0.03, -0.14, 0.85, ...]   ← very close to the above
"best biryani in Pune"       → [-0.71, 0.44, 0.09, ...]   ← far away

Once your text is vectors, "find the most similar meaning" becomes "find the nearest vectors" — a geometry problem. Similarity is measured by a distance: cosine similarity (the angle between vectors) is the usual one, with Euclidean and dot-product as alternatives.

What a vector database does

The hard part is scale. Finding the nearest of a few hundred vectors is easy — compare against all of them. Finding the nearest of fifty million by comparing against every one is far too slow for a live query.

So vector databases implement Approximate Nearest Neighbour (ANN) search: index structures — HNSW (a navigable graph, the most common) or IVF (inverted file / clustering) — that find almost the closest vectors in a fraction of the time. The word to notice is approximate: you trade a little accuracy (you might miss the true 1st and get the 2nd) for an enormous speed gain, and you tune that trade-off. This is the family's defining characteristic — everything else is plumbing around fast approximate nearest-neighbour search.

Where vectors are used

Almost always as part of an AI feature:

Semantic search — the password example: results by meaning, not keywords.
Retrieval-Augmented Generation (RAG) — the dominant use. To make a language model answer from your documents, you embed the documents, store the vectors, embed the user's question, retrieve the nearest chunks, and feed them to the model as context. The vector database is the "retrieval" in RAG, and it is why this family exploded.
Recommendations — "items similar to this one" by embedding items and finding neighbours.
Image / audio / video similarity — reverse image search, "find songs that sound like this", deduplication — anything you can embed, you can search by similarity.
Anomaly detection and clustering — points far from any cluster are outliers.

The honest positioning — and pgvector

This is the newest and most hyped family, so the this-course refrain matters most here: most applications do not need a dedicated vector database.

pgvector, a PostgreSQL extension, adds a vector column type and ANN indexing (HNSW and IVF) inside the database you already run:

CREATE EXTENSION vector;
CREATE TABLE docs (id bigint, content text, embedding vector(1536));
CREATE INDEX ON docs USING hnsw (embedding vector_cosine_ops);

-- the nearest 5 by cosine distance:  <=> is the distance operator
SELECT content FROM docs ORDER BY embedding <=> '[...]' LIMIT 5;

That is semantic search and RAG retrieval in PostgreSQL, alongside your relational data, in one system, with your transactions and backups. For the overwhelming majority of projects — up to millions of vectors — pgvector is the right answer, and you should reach for it before any dedicated vector database, for exactly the "one system is simpler" reasons that have run through this whole course.

A dedicated vector database (Pinecone, Weaviate, Qdrant, Milvus) earns its place only when vector search is central and at large scale: hundreds of millions to billions of vectors, very high query throughput, or a need for vector-specific features (advanced filtering during ANN, distributed sharding of the index, managed infrastructure) that outstrip the extension. That is a real tier — but it is a smaller set of projects than the hype implies.

Recognising the need

You need similarity/semantic search or RAG: you need embeddings and vector search — start with pgvector.
You are at hundreds of millions of vectors, or need vector-specific scale and features: consider a dedicated vector database.
You do not have an AI/similarity feature at all: you do not need vectors. Keyword or full-text search is the right tool, and reaching for a vector database because it is fashionable is this course's cardinal mistake in its most current form.

And a caveat worth stating: embeddings come from a model, and the vectors are only as good as that model. Different models give different, incompatible vectors; change the model and you must re-embed everything. The vector database stores and searches vectors — the meaning comes from the embedding model you chose, which is a decision outside the database.

Check your work

What a vector database stores and the question it answers. Embeddings (lists of numbers), and "what is most similar in meaning to this?"

What an embedding is. A model's conversion of text/image/audio into a vector positioned so similar meanings are close together.

Why keyword search misses semantic matches. It matches tokens, not meaning — "reset password" and "forgot login" share few words.

How similarity becomes a query. Find the nearest vectors; measured by cosine similarity (or Euclidean / dot product).

Why ANN, and what "approximate" trades. Exact nearest-neighbour over millions of vectors is too slow; ANN (HNSW, IVF) trades a little accuracy for a large speed gain.

The dominant use. Retrieval-Augmented Generation — embedding your documents so a language model can answer from them.

Four other uses. Semantic search, recommendations, image/audio similarity, anomaly detection.

What pgvector provides. A vector column and HNSW/IVF indexing inside PostgreSQL — semantic search and RAG in one system.

When pgvector is enough. The large majority of projects, up to millions of vectors.

When a dedicated vector database earns its place. Hundreds of millions to billions of vectors, very high throughput, or vector-specific features beyond the extension.

The caveat about embeddings. They come from a model; different models give incompatible vectors, and changing the model means re-embedding everything.

Practice

Explain, to someone non-technical, how "search by meaning" differs from "search by words", using the password example.
Describe what an embedding is and why similar meanings end up as nearby vectors.
Explain why comparing a query against all fifty million vectors is infeasible, and what ANN does about it.
Sketch the steps of a RAG pipeline and point at where the vector database sits.
Write the pgvector DDL for a documents table with a 1536-dimension embedding and an HNSW index.
Write the nearest-neighbour query with the <=> cosine-distance operator.
Decide, for an application you know, whether it has a genuine similarity/AI feature — and therefore whether it needs vectors at all.
For one that does, argue whether pgvector suffices or a dedicated database is justified. Most need only pgvector — say why.
Explain what breaks if you switch embedding models after loading a million vectors.

Official documentation

pgvector — The vector type, distance operators, and HNSW/IVF indexes for PostgreSQL.
Pinecone — Learn: vector databases — A clear vendor explainer of embeddings and ANN.
Weaviate — Documentation — A dedicated vector database, for context.
Qdrant — Documentation — Another, with a good concepts section.
HNSW algorithm (paper) — The graph index behind most ANN search, if you want the depth.

Next module: choosing, and using more than one.