Vector Databases Explained With a Real-World Example

Imagine a customer types: "How do I get my money back?"

Your help center has an article titled "Refund and Return Policy." The two share no keywords. A traditional database search finds nothing. A vector database finds it instantly.

How Does It Work?

An embedding model turns text into a list of numbers (a vector) that captures meaning. Think of it as coordinates on a giant map of ideas. "Get my money back," "refund," and "return my order" all land close together. "Change my password" lands far away.

The End-to-End Flow

1. Every help article is embedded and stored.
2. The user's question is embedded with the same model.
3. The database returns the nearest vectors by distance, usually cosine similarity.
4. Those articles become context for the LLM.

Why it's fast: Comparing a query against millions of vectors one by one would be slow. Vector databases use approximate nearest neighbor indexes like HNSW to find close matches in milliseconds, trading a tiny amount of accuracy for a huge speed gain.

What People Forget

• Metadata filtering: "Only search documents this user is allowed to see" or "only 2026 policies."
• Hybrid search: Exact terms like product codes or error IDs still need keyword search.
• Embedding model choice: Change the model and you must re-embed everything.

Options range from purpose-built tools like Pinecone, Qdrant, and Weaviate to pgvector, which adds vector search to PostgreSQL. For many teams, pgvector is enough to start.

A vector database doesn't understand anything. It just finds what's nearby, and that's exactly why the quality of your chunks and embeddings matters so much.

Are you using a dedicated vector DB or pgvector?