Vector databases: where your embeddings live

The moment you start embedding text (see the embeddings post), you have a storage problem: potentially millions of vectors that you need to search by similarity, fast. A vector database is the system built for exactly that — it's the backbone of most RAG systems.

What they actually do

A vector database stores high-dimensional vectors alongside metadata and runs approximate nearest-neighbour (ANN) search: given a query vector, it finds the closest stored vectors in milliseconds. It does this with specialised indexes — HNSW, IVF — that trade a sliver of accuracy for enormous speed, because exact search across millions of vectors would be far too slow.

The popular options

• Pinecone — fully managed and easy to start, popular for getting to production fast.
• Weaviate, Qdrant, Milvus — powerful open-source options (managed tiers available); Milvus in particular targets very large scale.
• Chroma — lightweight and developer-friendly, great for local development and prototypes.
• pgvector — a Postgres extension that adds vector search to a database you may already run.
• Redis — vector search on top of Redis, handy if it's already in your stack. (FAISS, by contrast, is a library for similarity search, not a full database.)

Dedicated database or pgvector?

If you already run Postgres and your scale is modest, pgvector is often the right call — no new system to operate. Reach for a dedicated vector database when you hit large scale, high query throughput, or need advanced metadata filtering and hybrid (keyword + vector) search out of the box. Choose on scale, your existing stack, managed-vs-self-hosted, and the filtering features you need — not on hype.

A vector database isn't exotic — it's an index optimised for 'find me the closest meaning', which is the one query RAG makes over and over.