Vector Search

Retrieval by semantic similarity: comparing embedding vectors to find items close in meaning rather than matching keywords.

Vector search finds things by meaning. Text, images or audio are converted by an embedding model into vectors, long lists of numbers that encode semantic content, and stored. A query is embedded the same way, and the system returns the nearest neighbors by cosine similarity or dot product. A search for invoicing tool for freelancers finds self-employed billing apps with zero keywords in common.

Why it matters to an indie builder: this is the retrieval half of every RAG system and the core of semantic search, recommendations, deduplication and clustering. The entry price collapsed: pgvector gives you vector search inside Postgres, and at small scale brute-force scanning is fast enough that you may never need a dedicated engine. When volume or filter complexity grows, Qdrant, Chroma, LanceDB and friends take over.

A concrete example: support docs search. Keyword search fails on how do I stop paying twice, because nothing matches the billing FAQ wording. Embed your 2,000 documentation chunks once (a one-time cost of a couple of cents), store them in pgvector, embed each incoming question, and return the five nearest chunks in about 20 milliseconds. The right FAQ surfaces, and the language model answering from it gets good context. Retrieval quality decides answer quality more than model choice does.

Common mistakes: embedding whole pages instead of chunking to a sensible size, ignoring metadata filters (vector search combined with a WHERE clause, this product, this locale, is what makes search usable), re-embedding the corpus on every query (only the query is new), and tuning ANN indexes at ten thousand vectors where brute force is still instant. Start in Postgres and graduate when latency tells you to; the vector-db blocks on IndieBoot lay out the graduation path.